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El universo. 


Las presentes páginas deben su existencia, sobre todo, al 
elevado número de cartas recibidas donde los lectores 


reclamaban la inclusión de tal o cual apartado dentro de 
Las imágenes 


re Rendermanía. Evidentemente, era imposible contentar a todos 


generadas 


por dentro del limitado espacio disponible en las 5 páginas de la 
programas 


que E Es ai S 
describen sección y por ello PCmanía ha tomado la decisión de ampliar 


objetos 3D. 

Rendermanía, la cual, desde ahora, 
pasa a ser un suplemento. Como nos 
gustan las sorpresas no desvelaremos 
los apartados de que constará la 
nueva Rendermanía, aunque, eso sí, 


confiamos que sean del gusto de 


todos los afectados por el virus 


infográfico. 


Ante todo, queremos agradecer al POV-Team la creación (y contínua mejora desde hace años) de lo que 
muchos pensamos que es el mejor trazador de rayos que pueda encontrarse para PC: El Persistence of Vision 
Raytracer (o sea POV). 

También, queremos agradecer a Roberto Potenciano, José González y Héctor Iniesta que nos prestaron su 
ayuda con los bitmaps y dieron sus opiniones en las escenas. 

Finalmente, queremos agradecer los estímulos, consejos. notas. utilidades, escenas y animaciones de todos 
aquellos lectores que, a lo largo del tiempo, con sus cartas y e-mails, nos han hecho comprender que la 
Infografía es algo más que la creación de imagen sintética. Es tambien algo que une a la gente. 
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- de POV 3.0....... 


Este primer número es espe- 
cial; ya que se dedica única y 
exclusivamente a POV 3.0. Su 
contenido está al alcance de 
cualquier novato, y se co- 
mentan características de la 
nueva versión 3.0, además 
de un pequeño proyecto re- 
alizado con dicha versión, 
para beneficio de los pov- 
maniacos más veteranos. 

Estas páginas han pasado 
por una larga evolución. En 
principio se perió hacer un 
pequeño libro sobre POV, 
luego se decidió esperar al 
lanzamiento de la versión 3.0 
y, finalmente, se tomó la de- 
cisión de crear un suplemen- 
to de infografía “práctica” cu- 
yo primer número dedica- 
mos al que ha sido caballo 
de batalla de Rendermanía 
durante tanto tiempo. 

En cuanto a este primer nú- 
mero, casi todas las imáge- 
nes se han creado usando 
una pequeña librería que se 
adjunta en el CD: castlito 1.8. 
Se trata de una librería de for- 
mas para construir castillos, 
pueblos - ciudades medie- 
vales con POV 3.0. Comen- 
zamos a desarrollar esta idea 
hace ya mucho -cuando los 
386 dominaban la tierra- pe- 
ro tuvo que abandonarse por 


falta de potencia del proce- 
sador, falta de memoria, falta 
de tiempo, y -sobre todo- 
por falta de ciertas sentencias 
en el lenguaje escénico de 
POV. Sólo ahora, con todas 
estas carencias, parcial o to- 
talmente enmendadas, se ha 
podido dar a castlibo un razo- 
nable grado de terminación 
(al menos en el apartado del 
pueblo). De hecho, toda la 
librería se reescribió varias 
veces bajo POV 2.2 para lue- 
go, tirarla al cubo y volverla a 
escribir bajo POV 3.0). Sin 
embargo, castlib está incom- 
pleta aún En el momento de 
escribir esto, muchas piezas 


necesarias para crear castillos 
aún estaban en fase de prue- 
ba. Por ello, se ha decidido 
extraer un fichero con el 
apartado que resultaba más 
completo: el de las casas 
precisas para construir una 
pequeña ciudad medieval. 
¿Y qué ordenador se pre- 
cisa? Algunas escenas pue- 
den requerir un 486 con 16, 
o mejor 32 Megas de RAM. 
Esto no significa, no obstan- 
te, que un usuario provisto 
de un ordenador menos po- 
tente haya de renunciar a se- 
guir los ejemplos. Castlib 
puede ser recortada para 
crear escenas más sencillas. 


Se entiende 
como 
“render” al 
proceso de 
generación 
de la imagen. 
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La idea en 
que se basa 
en Ray-tracing 
consiste en 
“lanzar” rayos 
desde la 
cámara para 
cada pixel de 
la escena a 
Calcular. 


Podemos definir el 
término Infografía 
como la rama 
relativamente nueva 
de la informática 
dedicada a la 
generación de 
imágenes por 
ordenador. 


Estas imágenes “sintéticas” 
son generadas por progra- 
mas que utilizan datos que 
describen objetos tridi- 
mensionales para universos 
virtuales que sólo existen en 
los ordenadores. Los resul- 
tados son moneda corrien- 
te para todos nosotros des- 
de hace ya años: anuncios, 
animaciones y clips de gran 
realismo aparecen de ma- 
nera cotidiana en la televi- 


sión y el cine. Un ejemplo 
ya clásico, es la película 
Terminator !H, donde a la 
imagen real se le añadía la 
generada por ordenador 
para el androide T1000. Ya 
antes se habían empleado 
efectos infográficos, pero 
quizá fue Terminator la pelí- 
cula que más hizo com- 
prender a todo el mundo 
las posibilidades de la info- 
grafía. Posibilidades que 


Mask, Jum 
Twister, Independence Day 
y muchas más. 

De todo esto se despren- 
de que una de las mayores 
ventajas de la infografía es 
la de permitimos crear, con 
un realismo creciente, obje- 


tos que no existen en el 
mundo real, que están en 
fase de diseño, o que nun- 
ca tendrán una existencia fí- 
sica. Podríamos, por ejem- 
plo, (si tenemos los 
programas y equipos ade- 
cuados) simular un tomado, 
pasear por la Constantino- 
pla de tiempos del empe- 
rador Heráclio, recrear la vi- 
da de una hormiga, el 
comportamiento de un 


ginación, el Único límite es- 
tá en la potencia de progra- 
mas y ordenadores y esta 
potencia aumenta de día en 
día, lo que esta permitien- 
do que la infografía tenga 
una presencia cada vez ma- 
yor en un campo tan popu- 
lar como el de los videojue- 
gos de PC («Doom», «Duke 
Nukem», «Quake», etc.). Por 
otro lado, otra de las razo- 
nes del creciente interés de 
la infografía es que cual- 
quiera tiene la posibilidad 
de llegar a hacer cosas inte- 
resantes. En principio basta 
con disponer del ordena- 
dor más difundido del pla- 
neta: el PC. 


Diversos tipos de 
render 

Existen muchos programas 
generadores de imágenes 
fotorealistas para todo tipo 
de platafomas y también 


Infografía y ' 


una gran cantidad de méto- 
dos o algoritmos distintos 
para generar imágenes por 
ordenador. Además, la im- 
plementación de un mismo 
método puede variar de un 
programa a otro, ya que los 
programadores pueden 
combinar diversos algorit- 
mos de sombreado, oculta- 
ción de superficies, trata- 
miento de color, etc., para 
construir el motor 3D del 
programa. 

(Llamamos motor 3D a la 
parte de código del pro- 
grama encargada del pro- 
ceso de Render. En cuanto 
proceso de Render en si, 
ende como tal al 
eración de 
la imagen. k ay, 
3D Studio, magia 
quier otro programa de este 
tipo, decimos que se está 
efectuando el Render cuan- 
do el programa está calcu- 
lando la escena, aunque és- 
ta no sea visible en 
pantalla). 

El trazado de rayos o Ray- 
tracing es, simplemente, 
uno de los muchos méto- 
dos existentes para la gene- 
ración de imágenes foto- 
realistas. Programas como 
POV, Polyray e Imagine uti- 
lizan el trazado de rayos 
mientras que otros como 
3D Studio no lo emplean. El 
trazado de rayos fue idea- 
do, en principio, como un 
algoritmo de ocultación de 
superficies y sólo posterior- 


mente se convirtió en un 
método de sombreado. 

(Un algoritmo es un meto- 
do para resolver un proble- 
ma dado. La ocultación de 
superficies es uno de los 
problemas básicos a los 
que debe enfrentarse cual- 
quier programador gráfico. 
Se refiere al proceso por el 
que se decide qué superfi- 
cies quedan más cerca del 
observador, a fin de repre- 
sentarlas en el orden co- 
rrecto. 

Un método de sombrea- 
do es cualquier algoritmo 
que emplee uno de los mu- 
chos modelos matemáticos 
de iluminación existentes 
para sombrear -dibujar-, de 
manera más o menos realis- 


Ray-Tracing 

La idea en que se basa el 
Ray-tracing consiste en “lan- 
zar” rayos desde la cámara 
u Observador para cada pi- 
xel de la escena a calcular. 
Estos rayos del “observa- 
dor”, al viajar por el universo 
virtual, pueden chocar o no 
con un objeto. Si este cho- 
que no se produce, el pixel 
toma el color del fondo. 

En caso contrario, el color 
del pixel se determinará 
dependiendo del color 
propio de la superficie, el 
color de las fuentes que in- 
cidan sobre él, etc. 

Debido a esto, este mé- 
todo es llamado también 
“de seguimiento de fayo os”. 
En Le | podría supo- 


TP pora? e que 15 lógico sería 


- trazado de rayos 


A 


C anto y 
major seal 
- complejidad 


de la escena 
mayor será el 
tiempo que 
precisará el 
PC para 
completarla. 
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para garántizar ría ilumirá-  eursivo'e i 
ción adeeváada para las ya 


-pefficies. Además 


muy similar al que 
obiénerse con una 
de/na escena similar 
en elínundo real. 
aturalmente no todo es 
de color de rosa, El modelo 
de iluminación del trazado 
de rayos funciona muy bien 
en casi todos los aspectos 
salvo en el de la luz difusa. 
¿Y qué es la luz difusa? 
Bien: todos los objetos físi- 
cos del mundo real reflejan 
la luz que reciben (salvo los 
cuerpos celestes llamados 
agujeros negros y los dispo- 


mágentés ge- 
con téénicas de 
-tracipg tienen un nivel 
muyélevado de realismo. 
Otros métodos de som- 
breado consiguen generar 
Imágenes en menos tiempo 
pero a cambio de un menor 
“foto-realismo” 


Dara-etfó, se lanzan desde 
ahí otros rayos -uno para 
cada fuente de luz definida 
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sifivos de camuflaje de las 
aves de presa Klingon, en 
tar Trek). Como la mayoría 
de las superficies del mun- 
do real son irregulares en 
mayor o menor medida, los 
rayos reflejados no abando- 
nan estas superficies con el 
mismo ángulo de inciden- 
Cia con que llegaron a ella. 
Es esta luz difusa la que ilu- 
mina a los objetos sobre los 
que no caen directamente 
los rayos de un foco de luz. 
También, es esta luz la que 
suaviza los bordes de las 
sombras. (Consideremos, 
por ejemplo, el aspecto de 
un Cuarto oscuro en el que 
se filtran los rayos de luz a 
traves de una persiana. Sin 
luz difusa no podríamos 
percibir a los muebles en 
penumbra). Para simular la 
luz difusa, los trazadores de 
rayos emplean un truco lla- 
mado iluminación ambien- 
tal, el cual, desgraciada- 
mente, no se acerca 
demasiado a la realidad. 
Otra limitación importan- 
te del modelo luminoso de 
los trazadores de rayos es 
que las fuentes de luz son 
puntos infinitamente pe- 
queños. Esto causa proble- 
mas con las sombras ya 
que, al no calcularse la luz 
difusa, las sombras tienen 
unos bordes excesivamen- 
te nítidos. (Esto puede en- 
mendarse, por ejemplo, 
empleando áreas de luz). 
Otros modelos luminosos 
que solucionan estas limita- 
ciones se basan en la “ra- 
diosidad”. Desgraciada- 
mente la radiosidad, a su 
vez, tiene problemas con 


las reflexiones especulares 
y requiere un tiempo de 
cálculo considerablemente 
superior incluso al precisa- 
do por el Ray-tracing. Si lo 
mencionamos es porque 
POV, a partir de la versión 
3.0, incorpora la radiosidad 
como opción. 

Así, en resumen, la canti- 
dad total de cálculos para 
crear una imagen es muy 
srande y cuanto mayor sea 
la complejidad de la esce- 
na mayor será el tiempo 
que precisará el ordenador 
para completarla. El proce- 
so puede durar minutos, ho- 
ras, días, o semanas enteras 
dependiendo también de la 
potencia del ordenador, o 
de la del propio Ray-tracing. 
Por esta razón, lo que aca- 
bamos de explicar sobre el 
trazado de rayos nos será 
útil más tarde, cuando estu- 
diemos los diversos méto- 
dos existentes para ahorrar 
tiempo de cálculo. 


¿Qué tiene POV de 
especial? 

Persistence of Vision Raytra- 
cer, abreviadamente llama- 
do Povray o POV, es el 
nombre del trazador de ra- 
yos sobre el que trata este 
suplemento. 

Persistence of Vision Team 
(o pov-team) es también el 
nombre del grupo de pro- 
gramadores que nació con 
la finalidad de crear el Ray- 
tracer POV. Hace ya unos 
cuantos años existían otros 
Ray-tracers para PC, recor- 
vertidos desde amiga en su 
mayor parte. Pero, insatisfe- 
cho con estos programas, el 


grupo formado por Drew 
Wells decidió crear un nue- 
vo Ray-tracer basado en el 
trazador de rayos DKBTrace 
de David Buck y Aaron Co- 
llins (los cuales se sumaron 
al proyecto). Con este fin se 
estableció el cuartel general 
del grupo en el foro 
GRAPHDEV de CompuSer- 
ve y, desde entonces, se 
han publicado varias versio- 
nes de POV con un éxito 
creciente. 

Actualmente, hay versio- 
nes de POV que funcionan 
bajo MS-DOS, Windows 
3.x, 95 y NT, Linux, Apple 
Macintosh 68k y Power PC, 
Amiga, UNIX y otras plata- 
formas. La última versión de 
POV la podéis encontrar en 
su dirección oficial vía Wet 
en http://www.povray.org, 
o vía ftp, en ftp.povray.org. 
Pero tanto el programa co- 
mo muchas de las utilida- 
des que se han creado para 


Las 
sentencias 
de POV 


crean 
objetos cuya 
forma viene 
definida por 
fórmulas. 


el se pueden encontrar en 
muchas direcciones más, 
por todo el mundo. 

¿Cuál es la razón de este 
éxito? En primer lugar, por 
supuesto, la increible calt- 
dad del programa. Los 
miembros del pov-team lle- 
van años trabajando ininte- 
rumpidamente para que 
POV no se quede estanca- 
do, como ha sucedido con 
otros trazadores de rayos 
que han acabado desapa- 
reciendo. En parte para ga- 
rantizar esta calidad, el 
pov-team es un grupo 
abierto, donde, según pa- 
rece, pueden entrar nuevos 
miembros, si estos tienen 
algo interesante que aportar 
al proyecto (esto fue lo que 
sucedió con Dieter Bayer y 
su FTpov). Este factor que- 
da reforzado por el hecho 
de que los fuentes de POV 
son de libre distribución. 


Cualquier programador 


puede compilar su propia 
versión We POV, e incluso 
incorpórar sus propios 
cambios, si tiene los cono-_.. 
cimientos y la capacidad 
necesarias (aynque debe 
indicar que se trata de una 
versión no oficial», 

Las característicasidel pro- 
grama que, prácticamente 
desde el principio, ofrecía 
una excelente relación tiem- 
po/calidad, atrajeron a mu- 
chos artistas que comenza- 
ron a publicar escenas 
creadas con POV. Esto a su 
vez estimuló la creación de 
utilidades específicas y la 
adaptación de otras para 
trabajar con POV. 

Por último, hay que citar 
un pequeño detalle: POV 
es de libre uso. No hay que 
pagar un céntimo por su 
empleo y esto, junto a su 
potencia y los factores an- 
tes citados, ha creado la 
bola de nieve que ha hecho 
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de POV el trazador de ra- 
yos más popular del mun- 
do PC. Es por estas razones 
que POV ha sido el caballo 
de batalla fundamental del 
suplemento Rendermanía y 
por esta misma razón se le 
dedican estas páginas. 


El trabajo con POV 

Para crear una escena con 
cualquier software de ge- 
neración de imagen de sín- 
tesis, ya empleamos traza- 
do de rayos o cualquier 
otro método, habremos de 
suministrar al programa una 
descripción de la escena a 
renderizar en un formato 
comprensible. Habrá que 
indicar la posición espacial, 
forma y propiedades de los 
objetos, la colocación y 
orientación de la cámara y 
las fuentes de luz, y muchos 
otros detalles más. El fiche- 
ro con la descripción nece 
saria puede crearse, básica 

mente, de dos maneras 


Programas 
como POY, 
Polyray e 
Imagine, utilizan 
el trazado de 
rayos. 
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distintas: usando un progra- 
ma de modelado o bien es 

cribiendo directamente el 
texto con la descripción, 
empleando lo que se llama 
un lenguaje escénico. 

El primer sistema es el 
que emplean paquetes co- 
mo 3D Studio, Imagine, Ca- 
ligari TrueSpace, Topas y 
otros. En cada uno de estos 
productos, la forma, el sis- 
tema de trabajo, y las op- 
ciones de cada modelador 
son diferentes, pero pode- 
mos destacar algunas carac- 
terísticas comunes: en todo 
programa de modelado 
existen una serie de opcio- 
nes para construir objetos 
simples como esferas, cu 
bos, conos, cilindros, etc., 
y también formas más com- 
plejas empleando métodos 
de extrusión, de revolución 
y otros. Luego, pueden rea- 
lizarse diversas operaciones 
sobre estos objetos inicia- 
les y obtener objetos aún 


más complejos. Después, 
podemos colocar cámara y 
luces, y ordenar la renderi 

zación de la escena. Mu- 
chas de estas operaciones 
pueden realizarse también 
con los lenguajes escénicos 
pero el empleo de un mo- 
delador es, en general, si 
esta bien diseñado, más rá 

pido e intuitivo. 

Veamos porque: en un 
modelador podemos acce- 
der a las distintas opciones 
empleando sistemas de 
ventanas o iconos, sin tener 
que escribir nada. Los obje- 
tos suelen visualizarse como 
mallas de hilos en una o más 
ventanas de trabajo con dis- 
tintas vistas y, lo más impor- 
tante, al ordenar una trans- 
formación cualquiera sobre 
un objeto, un desplaza- 
miento, una escalación, una 
operación CSG, etc., vere- 
mos el resultado en las ven- 
tanas de trabajo, sin necesi- 
dad de ordenar un render. 


En POV, y en otros pro 
gramas que carecen de mo- 
delador, el sistema es total- 
mente distinto. Usando un 
editor de texto cualquiera 
escribiremos un fichero 
que, empleando las senten- 
cias permitidas por el len- 
guaje escénico, describirá 
la escena. Luego, invocan- 
do al programa, le daremos 
como entrada el fichero es- 
cénico escrito y le ordena- 
remos su proceso. En caso 
de que haya algún error de 
sintáxis en alguna sentencia 
del texto de entrada, el 
programa no mostrará nada 
y se limitará a indicar el 
punto del error en el fichero 
de texto. Entonces, debe- 
remos corregir el error des- 
de el editor de texto y vol- 
veremos a ordenar el 
render. Otra posibilidad es 
que el programa renderice 
la escena pero los resulta- 
dos no sean los esperados, 
al haber cometido algún 
error lógico o espacial en la 
colocación de los objetos 
o en las operaciones entre 
estos. Cuando esto suceda, 
deberemos volver de nue- 
vo al editor de texto para 
arreglar el problema. Este 
sistema es, como se ve, 
idéntico al que sigue un 
programador para compilar 
su trabajo y la mayor pega 
está en que los resultados 
de las operaciones no se vi- 
sualizan “en tiempo real”, 
delador. 


bio necesitaremos ordenar 
un render). 

Pero no todas las ventajas 
están del lado de los mo- 


Sam] 


deladores. En primer lugar, 
algunas de las sentencias del 
lenguaje escénico de POV 
nos permitirán leer y emplear 
objetos creados con mode- 
ladores, con lo que, si dis 

ponemos de alguno, podre. 

mos aprovechar sus ventajas. 
Par otro lado, las sentencias 
de POV crean objetos cuya 
forma viene definida por fór- 
mulas y no por polígonos, 
como suele ser el caso de 
todos los modeladores. Es- 
to implica dos cosas: la pri- 
mera, que los ficheros crea- 
dos con un lenguaje 
escénico suelen ocupar mu- 
cho menos espacio que los 
archivos generados por los 
modeladores (incluso en el 


ES que los modelado- 


a 
Aaara? 


res realicen la grabación en 
algún formato comprimido 
propio). Pensemos, por 
ejemplo, en una esfera. Su 
definición tan sólo requerirá 
unas pocas palabras con un 
lenguaje escénico, pero 
cualquier modelador habrá 
de almacenar una lista de 
vértices y polígonos 

Otro efecto de esto es 
que una esfera definida por 
una fórmula es perfecta: por 
mucho que acerquemos la 
cámara a ella, seguiremos 
apreciando correctamente 
su esfericidad. En cambio, 
una esfera definida por polí- 
gonos tan sólo aparentará 
serlo si el número de polígo- 
nos empleado es lo bastante 
alto y la cámara no la enfoca 


a corta distancia. Finalmente, 
hay que añadir que la nueva 
versión de POV incluye im- 
portantes mejoras en el len- 
guaje escénico. Gracias a 
ellas, podremos conseguir 
escenas que impresionarán a 
Cualquier usuario de un pro- 
Srama de modelado (a me- 
nos, claro está, que dispon 

ga de un paquete cuyo 
coste sobrepase las 400.000 
mil pesetas o más). En todo 
caso, para quienes no lle- 
guen a acostumbrarse al len- 
guaje escénico, la populari- 
dad de POV ha propiciado 
la aparición de diversos mo- 
deladores que generan fi- 
cheros de escena directa- 
mente digeribles por POV. 
Estos modeladores repr: 


sentan los objetos de mane- 
ra “poligonal” pero graban 
las escenas empleando el 
lenguaje escénico de POV. 
Esto origina una serie de pro- 
blemas que parecen únicos 
de estas utilidades: no se re 

presentan bien las operacio 

nes CSG, no pueden leerse 
archivos de POV, etc. 

(Por ello, preferimos em- 
plear sólo el lenguaje escéni- 
co. La librería Castlito ha sido 
creada “manualmente”, sin 
emplear ningún modeladon.. 

Además, como estos 
modeladores están estre 
chamente relacionados 
con el lenguaje de POV.es - 


e pa 
todo lSque se pueda a es- 


Gra 


Las imágenes 
se crean 

por defecto 
con +Q9. 
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INMINCAO 


En las siguientes líneas 
vamos a analizar los 
pasos para instalar la 
nueva versión de POV. 
La versión cuya 
instalación vamos a 
comentar es la de PC 
bajo MS-DOS ya que es 
la más popular. Esta 
versión puede 
ejecutarse también 
desde una caja-MS 
DOS de Windows. 
(Temas que se trataron 
en el número 47 de 
PCmanía, con motivo 
de la publicación de 
POV, pero también nos 
parece adecuado 
insertarlos aquí). 


POV viene comprimido en 
un fichero llamado Povms- 
dos.zip. Deberemos guar- 


El uso de POV 


dar este fichero en un di- 
rectorio temporal y, desde 
allí, procederemos a des- 
comprimirlo usando el pro- 
grama Pkunzip. Hecho esto, 
aparecerá ante nosotros el 
verdadero paquete de ins- 
talación: Install.exe. Este 
programa requiere 600 Kby- 
tes de memoria convencio- 
nal y es autoexplicativo 
(aunque en inglés, claro). Al 
ejecutarlo, el programa so- 
licitará que especifiquemos 
un disco y un directorio 
donde guardar el paquete a 
instalar. Hecho esto, se pro- 
cederá a realizar la instala- 
ción, creándose una serie 
de subdirectorios dentro 
del directorio que hayamos 
indicado al programa de 
instalación. Al finalizar el 
proceso, aparece un texto 


del coordinador del Pov- 
team, explicando algunos 
detalles sobre la versión. 


Town.inc 

Con este suplemento inclui- 
mos la versión 1.8 de castlito 
compuesta por un Único fi- 
chero llamado town.inc. 
Además, se incluyen los fi- 
cheros de escena llamados 
escenaxx.pov, los ejemplos 
llamados ejempxx y los fi- 
cheros bat. 

(Las xx indican el número 
de escena o ejemplo). Lo 
ideal es crear un nuevo sub- 
directorio -al que desde 
ahora nos referiremos por el 
nombre: media- dentro del 
directorio de POV. Será en 
este subdirectorio donde 
ejecutemos todos los ejem- 
plos de uso de la librería. 


Ejecutar POV bajo 
DOS y Windows 
Como sucedía en versiones 
anteriores, el fichero autoe- 
xec.bat deberá indicar un 
path a povray.exe si desea- 
mos ejecutar el programa 
desde cualquier directorio. 
También, deberemos espe- 
cificar el path a los nuevos 
ficheros include usando la 
orden “L” de la línea de co- 
mandos. Una vez impartida 
la orden a POV, el programa 
funcionará igual que siem- 
pre, aunque con algunos 
pequeños cambios, En pri- 
mer lugar, cuando la imagen 
termine de generarse, POV 


PLA Ed AAN 


no saldrá al DOS, sino que 


nos permitirá observar disA, 
tintas pantallas informativas | 


con estadísticas, opciones 
usadas en la generación, e 
información del programa. 
Podremos cambiar de una 
pantalla informativa a otra, 
usando las teclas de flecha 
y salir de POV con Return. 
En caso de fallo, POV nos 
dará la posibilidad de exa- 
minar dos pantallas adicio- 
nales “Error” y “Debug”. 

Por otro lado, como se ha 
dicho antes, la versión MS- 
DOS de POV puede funcio- 
nar desde una caja DOS de 
Windows. Teóricamente, 
podemos lanzar varios ren- 
ders simultaneamente em- 
pleando varias cajas pero, 
como podéis imaginar, esto 
no es demasiado práctico. 
Por un lado, una Única CPU 
deberá repartir su tiempo 
entre dos o más procesos 
de render, con lo cual no 
ganaremos tiempo con res- 
pecto a una lista de renders 
secuenciales (ordenados 
desde un fichero bat). Otro 
posible inconveniente está 
en la visualización. 

Aunque la generación de 
la imagen sea correcta, es 
posible que haya fallos de 
visualización al cambiar de 
una “caja-Dos” a otra. 


Documentación 

POV siempre ha contado 
con una excelente docu- 
mentación en inglés que, 
en la nueva versión, ha sido 
ampliada y apoyada por la 
inclusión del programa Pov- 
help, con el que podremos 
acceder a cualquier tema, 


desplazándonos con las te- 
clas de flecha sobre los tí- 
tulos y pulsando Enter para 
acceder a los temas. 

También, para quienes lo 
prefieran así, resulta posible 
obtener un fichero ASCII 
con el manual, usando la si- 
guiente línea: 

phe2txt -¡povhelp.phe -f 


Ficheros .inc y 

escenas de ejemplo 
Otra valiosa fuente de infor- 
mación para el povmaníaco 
novato está en los muchos 
ejemplos que incluye POV. 
Estos ejemplos son ficheros 
ASCII con una descripción 
de una escena tridimensio- 
nal formulada usando las 
sentencias permitidas por 
el lenguaje escénico de 
POV, como antes se dijo. 
Los archivos de POV, usan 
siempre las extensiones 
-pov o .inc para indicar que 
son ficheros escénicos de 
este Ray-tracer. Un escena 


de POV puede usar no o 
muchos de estosarchivos: 
Usualmente en cada < 
yecto sólo habrá un archivo 
con la extensión .pov. Este 
fichero será el principal y el 
que cargará a los archivos 
Inc con órdenes include. 
Como ya supondréis, cual- 
quier proyecto descrito 
con estos archivos debe 
definir una cámara que “re- 
trate” la escena, luces que 
la iluminen, y objetos diver- 
sos. Si alguno de estos tres 
tipos de elementos no se 
incluye en el proyecto, el 
resultado será una pantalla 
en negro. 

En su versión 3.0, el usua- 
rio puede consultar diver- 
sos tipos de ejemplos: en 
el directorio Pov3demo ve- 
remos varios subdirecto- 
rios, cada uno de los cuales 
incluye varios ejemplos del 
tema a que hace referencia 
el nombre del subdirecto- 
rio: atmos (efectos atmosfé- 


Escena a 
390x! 


pixels de. 
resolución: 
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_POW), lights Ucesy etc. 


HCOS), e de 
uso de la camara), opio 
(uso de los objetos Simpjés 
que pueden crearsg“con 


feadas usando 
sentencias del lenguaje de 
POV y el lector puede exa- 
minar las definiciones en el 
directorio llamado include. 

La manera ideal de estu- 
diar el lenguaje escénico es 
realizar experimentos con 
los ficheros del directorio 
pov3demo, ya que son los 
más recientes. En particular 
con los ficheros de objects, 
camera y lights. Podremos 
probar las órdenes de la lí- 
nea de comandos o probar 
cambios en las sentencias 
de los ficheros y aprender 
de ello. (También conviene 


hacer copas de los ficheros 


cheros de ejemplo pueden 
usarse como punto de parti- 
da para crear nuestras pro- 
pias escenas. 
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teando continuamente con 
las líneas de órdenes, pue- 
den usarse diversas altemati- 
vas. La primera es tener uno 
o más ficheros bat para invo- 
car a POV con los comandos 
y órdenes pertinentes. 

Otra posibilidad es crear 
ficheros ini, donde escribi- 
remos una lista de opcio- 
nes por defecto. Los fiche- 
ros ini admiten los mismos 
comandos que las líneas de 
órdenes y podemos invo- 
carlos desde la línea de ór- 
denes, y mezclar su uso 
con comandos de línea. 
Veamos por ejemplo: 
POVRAY RES800 +lprue- 
ba.pov +oprueba.tga. 

a primera palabra de la 


' pS ini, y 
luego dos comandos ge+ 


+Hn Resolución vertical de la imagen a generar. N es la altura en pixels. 
+Wn Resolución horizontal de la imagen a generar. N es la anchura en pi- 
xels. 

+D Activa la visualización de la escena mientras se va generando. 

-D La desactiva. 

+Dn Activa la visualización en el modo gráfico número n. 

Lista de tarjetas soportadas por +D +DO Autodetección de (S)VGA type 
(puesta por defecto) +D1 Standard VGA 320x200 +D2 Standard VGA 360 
x 480 +D3 Tseng Labs 3000 SVGA 640x480 +D4 Tseng Labs 4000 SVGA 
+D5 AT8T VDC600 SVGA 640x400 +D6 Oak Technologies SVGA 640x480 
+D7 Video 7 SVGA 640x480 +D8 Video 7 Vega (Cirrus) VGA 360x480 +D9 
Paradise SVGA 640x480 +DA Ahead Systems Ver. A SVGA 640x480 +DB 
Ahead Systems Ver. B SVGA 640x480 +DC Chips € Technologies SVGA 
640x480 +DD ATI SGVA 640x480 +DE Everex SVGA 640x480 +DF Trident 
SVGA 640x480 +DG VESA Standard SVGA Adapter +DH ATI XL display 
card +DI Diamond Computer Systems SpeedSTAR 24X +Dnp Idem. que 
orden anterior pero usando el modo de paleta número p. 

Lista de tipos de paleta soportados +D?3 Paleta 332 (la usada por defec- 
to). Esta compuesta por 256 colores con 3 bits para el componente rojo, 3 
para el verde y 2 para el azul. 

+D?0 Paleta de 256 colores que usa el sistema de color HSV. 

+D?G Usa una paleta de 64 tonalidades de gris. 

+D?H Opción HiColor (32000 colores con 5 bits por componente). 

+D?T Opción Truecolor (cotor real). 24 bits bajo Vesa 

Cuando solo nos interesa visualizar una pequeña zona de la imagen (por- 
que solo se esperan cambios en ella), utilizamos los siguientes 4 coman- 
dos: +SCn La columna n sera la inicial del recuadro parcial a renderizar. 
+ECn Para el mismo recuadro, n sera la columna final. 

+SRn Columna inicial del recuadro. 

+ERn Columna final del recuadro. 

+X Permite interrumpir la generación de la imagen pulsando una tecla. 
+C Permite reanudar el calculo de una imagen interrumpida con +X. 

+P Al finalizar el cálculo de la imagen, POV esperara a que se pulse una te- 
cla para salir. Usamos +p para ver la imagen cuando ha concluido el car 
culo. +P se usa junto a +D. 

+V Cuando, por la razón que sea, decidimos desconectar el display de la 
imagen (-D), puede ser conveniente saber que línea esta calculando POV 
en cada momento. Con +V activaremos esto. En caso de que se active la 
visualización (+D), deberemos usar -V. 

+Iname Junto a +l, se indica el nombre del fichero escénico de entrada. 
+0name Junto a +0, se indica el nombre del archivo gráfico de salida. 
+Lpath Por defecto POV sólo examina el directorio en curso para buscar 
los ficheros include que solicita el fichero .pov que se va a calcular. Con la 
opción +1 podremos indicar una ruta a un directorio donde hayamos al- 
macenado ficheros de inclusión. Es posible emplear varias ordenes +L. 
+0x El valor xindica la calidad del render. Valores de 0 o 1 usaran sólo ilu- 
minación ambiental, 2 y 3 usarán luz difusa, 4 renderiza sombras y 5 apli- 
ca luces zonales, 6 y 7 calculan texturas, el valor 8 calculará rayos refleja- 
dos, refractados y transmitidos y a partir de 9 se calcularan halos. El valor 
por defecto es 9. 

+0R Se calcula la radiosidad de la escena. 

+Bx Normalmente, cada vez que concluye el cálculo de una línea, POV la 
graba en el archivo gráfico de salida. Si queremos minimizar el número de 
grabaciones emplearemos este comando cuyo valor x es el número de 
Kbytes reservados para el buffer de grabación. 

+A Activa el antialias al valor por defecto (0.3). El antialias se emplea para 
suavizar la apariencia “dentada” que tienen en la escena las líneas diago- 
nales. Por defecto el antialias esta desactivado (-A). 

+Ax Cambia el valor para el antialising. 

+Kx Usada para pasar un valor x en flotante a la variable clock que es em- 
pleada por POV para hacer animaciones. 

+MVx Emplea la sintaxis de la versión x de POV (para ejecutar escenas 
antiguas). 

+SPx Usa un efecto de mosaico que nos permite hacernos una idea del 
aspecto general de la imagen antes de que esta se calcule por entero. Sí 
por ejemplo x=16, se calcularan y visualizaran puntos de 16x16 pixels. 
Luego la representación pasará a puntos de 8x8 pixels, y asi hasta llegar al 
cálculo pixel a pixel. 


Aaarra? y 


nea de órdenes que indi- 
can, primero, el nombre del 
fichero escénico a procesar 
y, después, el nombre del 
archivo gráfico a producir. 
En los ficheros ini las opcio- 
nes pueden especificarse 
también con ciertas pala- 
bras en vez de con coman- 
dos de línea pero, al ser un 
tema algo redundante, no 
las trataremos en esta oca- 
sión. Nos limitaremos a los 
comandos de línea más im- 
portantes, los cuales pue- 
den verse en la figura 1. 
Ahora, veamos varios ejem- 
plos con estos comandos. 

Situándonos dentro del 
directorio media probemos 
la siguiente línea: 

povray +lejempl.pov +0e- 
jemp1.tga+d0-v+w320 
+h9200-+IcApovray3Wnclude. 

El fichero de ejemplo 
ejemp1.pov será procesa- 
do y se creará un fichero tga 
con el mismo nombre. POV 
autodetectará la tarjeta dis- 
ponible y visualizará la es- 
cena a una resolución de 
320x200 pixels, sin antialias. 
Los ficheros include nece- 
sarios para la generación se 
buscaran en la ruta indicada 
por el comando +L. 

Si ahora probamos nueva- 
mente la línea precedente 
añadiendo +Q4, obtendre- 
mos un resultado mucho más 
pobre a cambio de una ma- 
yor velocidad de generación. 


Consejos sobre 
comandos de línea 


Como veremos más ms 


te, antes de obtener el ri 
sultado “final buscado en 
uha escena hay que realizar 


bastantes pruebas, hay que 
construir cada objeto, po- 
nerlo en su posición ade- 
cuada, elegir las texturas, la 
iluminación adecuada, etc. 
Una buena resolución para 
una escena final puede ser 
800x600 pixels, pero resulta 
absurdo calcular las pruebas 
intermedias con estos valo- 
res. Normalmente 320x200 o 
incluso 160x100 pixels, sue- 
len ser cifras más prácticas 
para W' y “H' durante los ren- 
ders de prueba. Además de 
esto, puede usarse la opción 
+SP con valores de 8 0 4. 
También, conviene utilizar 
el buffer poniendo +B con 
valores de 64 o más. De este 
modo, ahorraremos algo de 
tiempo y nuestros oídos su- 
frirán menos con el ronroneo 
del disco duro. Rebajar la ca- 
lidad del render no es tan 
buena idea como en princi- 
pio pudiera parecer. La pér- 
dida de calidad puede des- 
pistar bastante y, a la larga, 


hacemos perder el tiempo. 
Es preferible hacer pruebas 
parciales a calidad total y 
desactivar los elementos de 
la escena que no vayan a 
comprobarse en las prue- 
bas. Otra buena idea es de- 
sactivar el antialias (-A). El 
cálculo del antialias siempre 
requiere tiempo adicional y 
sólo tiene sentido activarlo 
en el render final. 

Por último es conveniente 
conservar la posibilidad de 
poder interrumpir siempre la 
generación de la imagen a 
golpe de tecla((+X), ya que 
más de una vez percibire- 
mos fallos garrafales mucho 
antes de que la escena se 
haya generado por comple- 
to. Si la interrupción se efec- 
tua en medio de una imagen 
importante, para continuar 
con ella posteriormente bas- 
tará con añadir +C a su línea 
de ordenes. Los comandos 
SC, EC, SR y ER, rara vez se 
emplean para nada. 


En cuanto al comando 'D', 
si se tiene una tarjeta mínima- 
mente modema, lo más con- 
veniente es usar +DGH o 
+DGT. No visualizar la ima- 
sen (-D) apenas ahorrará 
tiempo y perderemos la po- 
sibilidad de darnos cuenta 
pronto de si hay un error. 
POV, por defecto siempre 
genera un archivo tga. Si no 
especificamos un nombre 
para él, éste será output.tga. 
Si queremos evitar su crea- 
ción podemos hacerlo con 
-F pero..., ¿para qué hacer 
esto? Siempre puede ser útil 
organizar y guardar cada 
prueba. Podemos examinar- 
las usando algún visor de fi- 
cheros gráficos como al- 
chemy e incluso convertir los 
ficheros tga a jps, si el espa- 
cio ocupado se dispara. Más 
tarde volveremos nuevamen- 
te al aspecto “tiempo”, ya 
que es un detalle crucial en 
el trabajo con un trazador 
de rayos. 
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Escena 
iluminada 
con una 
fuente de 
color blanco. 


Podemos pensar en el 
universo virtual de POV 
como un espacio que 
se extiende 
infinitamente en todas 
direcciones. En este 
universo tridimensional 
todos los elementos: 
objetos, cámaras y 
luces, han de tener 
una colocación 
espacial que se 
declarará con tres 
valores de 
coordenadas para los 
ejes X,Y y Z. 


Si recordamos algunas no- 
ciones básicas de geome- 
tría, sabremos que los ejes 
eran conceptos abstractos 
utilizados para situar puntos 
u objetos en el espacio. El 


El universo tridim 


punto donde se cruzaban 
los ejes era llamado “origen 
de coordenadas” y asumire- 
mos que es el centro del 
universo del Pov-espacio. 
Naturalmente, las coordena- 
das X,Y y Z de este origen 
son <0,0,0>. Si imaginamos 
que este punto correspon- 
de al centro de nuestra pan- 
talla de ordenador, podre- 


mos visualizar el eje Xcomo__ 


una línea invist 
rre horizontalme 
monitor, siendo el eje Y una 
línea similar que cruza verti- 
calmente el centro de la 
pantalla y el eje Z otra línea 
que corta perpendicular- 
mente el plano de la misma, 
entrando o saliendo de ella. 
De esta manera, y siempre 
asumiendo que el centro de 


e nuestro 


la pantalla corresponde al : 
origen de coordenadas, las 
posiciones del eje X, situa- 
das a la derecha del men- 
cionado origen, son positi- 
vas y las situadas a la 
izquierda negativas. Las po- 
siciones del eje Y que que- 
dan por encima del origen 
son positivas, y las inferiores 
negativas. En cuanto al eje Z, 
asumireppos que la parte del 
mitbo Mud 
monitor es positiva y | ? 
opuesta negativa. Todos los É 
valores crecen positiva o ne- 
gativamente conforme los 
objetos se alejan del centro 
de coordenadas. 

Esta disposición en la co- 
locación y en el sentido de 
los ejes es totalmente arbi- 
traria y otros programas em- 
plean convenios diferentes. 
Por lo que respecta a las 
unidades utilizadas en Pov, 
podemos suponer que es- 
tán en metros, en micras, en 
años-luz, o en cualquier otra 
medida mientras trabaje- 
mos de manera consistente 
y respetemos las relaciones 
de tamaño entre objetos. 


Objetos virtuales 
El lenguaje escénico de 
Povray nos permite definir 
un universo tridimensional 
poblado de objetos virtua- 
les. Estos objetos pueden 
ser muy simples o extrema- 
damente complejos, de- 
pendiendo de lo que nues- 
tra imaginación, habilidad 


ensional del POV 


artística, o paciencia, nos 
permitan. Podemos crear 
modelos complejos a partir 
de muchos objetos simples, 
situarlos en el espacio, ilu- 
minarlos, y enfocarlos con la 
cámara desde cualquier po- 
sición. Además, habremos 
de definir la apariencia de 
estos objetos. En el mundo 
real las superficies pueden 
ser rugosas o lisas, mostrar 
los caprichosos dibujos del 
mármol o las líneas ondula- 
das de la madera, exhibir 
brillos metálicos, etc. 
OV, todas estas pro- 
piédade).se definen en las 
texturas eE ano los 
objetos. Elegir E 
rrectamente las texturas ¿n 
los objetos es algo tan vital 
como la propia forma de es- 
tos. La definición de una tex- 
tura puede ser algo muy sen- 
cillo o bastante complejo 
pero no nos asustemos: POV 
incorpora una completa li- 
brería de texturas con apa- 
riencias de maderas, mármo- 
les, granitos, cielos, etc. 
Veamos el formato gene- 
ral que sigue la definición 
de un objeto: tipo_obje- 
to(posicion_tamaño_y_orie 
ntación transformaciones 
textura[propiedades trans- 
formaciones) transforma- 
ciones) Las llaves definen el 
“ámbito” de las sentencias 
que definen al objeto. O 
sea que las sentencias pro- 
pias de la definición de la 
textura deben estar encerra- 


LL Fab es m 


das entre las llaves corres- 
pondientes de la misma y 
lo mismo ocurre con las 
transformaciones espaciales 
del objeto. Si hay alguna 
llave de más o de menos, o 
si la colocación de las ins- 
trucciones no corresponde 
a la que debe ser en el 
apartado correspondiente; 
obtendremos un error y la 
escena no se creará o cuan- 
to menos no se creará co- 
rrectamente. En cuanto a la 
palabra “transformaciones”, 
se refiere a las transforma- 
ciones espaciales: trasla- 
ción, rotación y escalación 
y su uso es siempre opcio- 


tobas ea 
ción. Por ejemplo, en el for- 
mato general antes descrito 
la palabra transformación fi- 
gura tres veces: en la prime- 
ra, la transformación sólo 
afectaría al objeto en sí pe- 
ro no a la textura ya que la 
definición de ésta sigue 
después. Por el contrario, la 
siguiente vez la transforma- 
ción afecta sólo a la coloca- 
ción, escala y orientación 
de la textura y no al objeto, 
que no sufre estos cam- 
bios. Esto es así porque la 
palabra está delimitada por 
las llaves de la definición 
de la textura. 

Por último: la tercera 
transformación afectará por 
igual a la forma y a la textura 
del objeto. 


por 


Fuentes de luz 

El universo espacial de POV 
está, por defecto, a oscu- 
ras. Para poder ver algo ten- 
dremos que crear, al me- 
nos, una fuente de luz. Las 
fuentes de luz son declara- 
das y tratadas como obje- 
tos, con la salvedad de que 
son puntos infinitamente 
pequeños: no pueden, 
pues, ser vistas.ya que care- 
cen de tamaño y forma. Es- 
to es así por cuestiones téc- 
nicas, ya que todos 
rayos luminosos han de salir 


del mismo punto, lo que a 
su vez provoca los nl 


mas mencignados al Princi- 
cerglas sombras. 
verdad es que POV 
emplea diversos trucos pa- 
ra paliar estos problemas. 
En cuanto a los tipos de 
fuente, la más utilizada y 
sencilla -y a la vez la que 
menos cálculos requiere- es 
la fuente de tipo omnidi- 
reccional. Ésta derrama su 


luz en todas direcciones, tal 


é A a 


Una vista de 
nuestra casa 
desde una 
cámara 
diferente de 
POV. 
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Una cámara 
de POV. 


como lo hace, por ejemplo, 
el sol. Veamos cómo crear 
una fuente de este tipo: 

light_source [ <30, 20, - 
50> color White) 

Como vemos los datos 
de la fuente de luz quedan 
encerrados entre llaves, de 
manera similar a como su- 
cedía en los objetos virtua- 
les. Las llaves que delimitan 
la definición de esta fuente 
engloban dos datos: un 
vector utilizado para indicar 
la posición espacial de la 
fuente en el universo virtual, 
y el color de la misma. Los 
vectores son profusamente 
utilizados en POV y más tar- 
de los trataremos con ma- 
yor detalle. En este momento, 
nos bastará con saber que el 
vector del ejemplo señala la 
posición X, Y y Z de la fuente. 
Después del vector, sigue la pa- 
labra reservada “color”, la cual 
se emplea para especificar 
aquello que su nombre indica. 

Una de ellas es precisa- 
mente la empleada en el 
ejemplo anterior: la palabra 
White (blanco) es en reali- 
dad un identificador o ma- 
cro definida con Hdeclare 
en el fichero de inclusión 
colors.inc. Si incluimos en 
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nuestro fichero escénico la 
sentencia precisa (Hinclu- 
de) para cargar este fichero 
inc, podremos referenciar 
cualquier identificador in- 
cluido en el mismo. El fun- 
cionamiento de esta espe- 
cie de macro es muy 
sencillo: al hallar el nombre 
del identificador, Pov lo 
sustituye por el texto que, 
en la declaración, sigue al 
identificador. Esta potente 
idea, que examinaremos en 
profundidad en la senten- 
cia declare, es la base de 
gran parte de la potencia 
del lenguaje de POV. El lec- 
tor puede examinar el fi- 
chero colors.inc (en el di- 
rectorio include) para 
comprobar la lista de colo- 
res “declarados” por POV. 

(Es muy importante recor- 
dar que POV distingue entre 
mayúsculas y minúsculas. 
Cuando usemos una senten- 
cia o un identificador tendre- 
mos que escribirlo tal como 
se indique. En el ejemplo an- 
terior white o WHITE no se- 
rían reconocidas por POV y 
obtendríamos un error). 

En el fichero colors.inc 
viene definido un buen nú- 
mero de colores pero, te- 
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niendo en cuenta que mu- 
chas tarjetas pueden mostrar 
hasta 16 millones de colores, 
es obvio que necesitamos un 
método alternativo para es- 
pecificar el color de la fuente 
de luz o de los objetos. 


El color 

El sistema RGB utiliza una 
mezcla de tres colores pri- 
marios para representar 
cualquier color. Es el siste- 
ma utilizado por los televi- 
sores a color y el empleado 
también por POV. Por tanto, 
deberemos definir cual- 
quier color utilizando inten- 
sidades de red (rojo), green 
(verde) y blue (azub).. POV 
emplea varias sintaxis para 
especificar colores. Una de 
ellas, algo antigua ya, es: co- 
lor red 1 green 0 blue 0. 

Los valores en formato 
flotante que siguen a cada 
color primario indican la 
fuerza del mismo y pueden 
oscilar desde O (nada) a 1 
(máxima intensidad). 

El ejemplo anterior es, 
evidentemente, la defini- 
ción del rojo puro y, como 
los otros dos componentes 
están a cero, podemos es- 
cribir tambien: color red 1. 

Pero esta sintaxis es algo 
engorrosa y por ello la si- 
guiente línea también es vá- 
lida: color rgb <1, 0, 0>. 

De hecho, también pode- 
mos precindir tranquila- 
mente de la palabra color y 
limitamos a: rgb <1,0,0>. 

Además, por una propie- 
dad de POV llamada “pro- 
moción de operadores”, es 
válida una línea como: rgb 1. 

que es la definición del 


color blanco. Ahora pase- 
mos a otros detalles. 

Realmente, la especifica- 
ción de un color, aunque 
puede limitarse a tres valo- 
res, puede emplear hasta 
cinco componentes. El 
Cuarto es llamado filter Cfil- 
tro) y se usa para indicar la 
cantidad de transparencia 
de un material. 

Un valor de cero en este 
componente señala una 
opacidad total y un valor 
de 0 una transparencia total. 
Veamos la definición de 
color usada en el fichero 
sglass.inc para crear una tex- 
tura empleada para las bo- 
tellas de vino: color rgbf 
<0.4, 0.72, 0.4, 0.6>. 

El cuarto valor equivale a 
una transparencia del 60%. 
Como podemos suponer, 
aún sin efectuar ningun ren- 
der, el color del material se- 
rá más bien verde, ya que 
tiene un fuerte valor en este 
componente. En cuanto al 
quinto componente, indica 
la cantidad de luz no filtra- 
da que se transmite a traves 
de una superficie. Ejemplos 
de este tipo de transparen- 
cia (que no existía antes de 
la versión 3.0) pueden ob- 
servarse en cortinas o telas 
finas. Este componente es 
llamado transmit y podemos 
agregar una 't' a la palabra 
rgb para aludirlo. Así usando 
rgbt, el cuarto valor corres- 
ponderia a este componen- 
te y en rgbft al quinto. 

Por último, hemos de tener 
en cuenta que, al igual que 
sucede con el mundo real, el 
color de un objeto depende 
también de la fuente de luz, 
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sobre todo si la superficie 
del objeto permite un alto 
índice de reflexión 


La cámara: cómo 
situarla y orientarla 
Al igual que sucede con las 
fuentes de luz, las cámaras 
son objetos invisibles. Cada 
escena debe incorporar 
una definición de la cámara 
que va a sacar la “fotogra- 
fía”. En dicha definición le 
indicaremos al programa 
donde situar nuestra cámara, 
hacia donde va a mirar, si va 
a tener zoom o no, etc. Así, 
como vemos, en la coloca- 
ción de las cámaras tiene lu- 
gar un proceso muy similar 
al seguido por un fotógrafo 
o un director de cine. 

(Sobre todo porque exis- 
te la posibilidad de crear 
películas con las imágenes 
generadas con POV). 

Aquí tenemos una posi- 
ble definición para la cáma- 
ra de una escena: camera ( 
location <0, 145, -120.0> 
direction <0.0, 0.0, 1.5> up 
<0.0, 1.0, 0.0> right 
<1.33,0.0, 0.0> look_at <3, 
10,0.0>). 

La colocación de la cá- 
mara en el espacio se logra 
con la instruccion Location. 
Esta sentencia utiliza tres 
números que indican la co 
locación de nuestra cámara, 
con respecto al origen de 
coordenadas. En el ejem- 
plo anterior, nuestra cámara 
estará situada a 120 unida- 
des fuera del monitor (si 
damos por válido el ejem- 
plo que se comentó al ex- 
plicar el sistema de coorde- 
nadas, donde se dijo que el 


É 


valor O de Z estaba situado 
en el plano de la pantalla. 
Según este mismo ejemplo, 
si el valor 120 fuera positivo, 
la posición caería dentro 
del monitor y la escena se 
enfocaría desde el lado 
opuesto). Además, la cáma- 
ra se posicionará a 145 uni 
dades por encima del ori 
gen (por el valor del eje Y). 
Look_at es, aparte de lo- 
cation, la instrucción más 
importante dentro del gru- 
po de las que componen la 
declaración de la camara. 
Especifica la posicion hacia 
la que esta va a mirar, for- 
zándola a sirarse para enfo 
car la posición espacial in- 
dicada en el vector que 
sigue a look_at. En el ejem- 
plo anterior, la cámara enfo- 
caría un punto colocado a 
la derecha y un poco por 
encima del origen de coor- 
denadas (ya que Z=0). La 
sentencia direction indica la 


dirección inicial de enfo- 
que de la cámara, dirección 
que, luego, puede ser cam- 
biada por las sentencias lo- 
ok_at,, rotate u otras. La lí- 
nea de enfoque de la 
cámara sigue el camino in- 
dicado por el vector de di- 
rectión (normalmente 
<0,0,1>). La longitud de es- 
te vector, 1.5 en el ejemplo, 
también afecta la distancia 
de la ventana de visión a la 
cámara. Una valor grande 
da como resultado un cam- 
po de visión corto, ya que 
el plano de visión quedará 
muy próximo a la cámara. 
La instrucciones up y right 
definen respectivamente la 
dirección vertical y horizon- 
tal del plano de visión. Tam- 
bién afectan al aspect ratio 
de la Imagen a “fotografiar”. 
En el ejemplo, up tiene el va- 
lor 1 en el eje Y vertical y night 
el valor 1.33 en el eje X. Con 
ello, se indica que la cámara 


no tiene ninguna inclinación 
con respecto al plano X,Z, tal 
como sucedería si estuviese 
apoyada en un tripode que- 
dando paralela al suelo. En 
cuanto al valor 1.33, normal- 
mente las resoluciones para 
las imágenes a generar suelen 
ser de 640x480, 800x600, 
10924x768, etc. Estos valores 
tienen una relación de 1.33 
(640/480, 800/600, etc). Por 
ello, colocando esta relación 
en right se efectúa una com- 
pensación, de modo que los 
objetos no quedan distorsio- 
nados. En las figuras pode- 
mos ver un ejemplo, cuya 
longitud es idéntica en los 
ejes Xey 

Teóricamente, usando tan 
sólo las sentencias location, 
direction, up y right, resulta 
posible colocar y orientar la 
cámara de cualquier forma 
pero, en la práctica, esto es 
muy difícil, y por ello, conta- 
mos con la ayuda de look_at. 


Otra cámara 
de POV. 
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Primitivas 
complejas de 
POV: objetos 
fractales. 


Componentes del 


Los componentes del 
lenguaje escénico de 
POV son 
identificadores, 
sentencias, vectores, 
cadenas, simbolos 
especiales y 
comentarios. Todos 
estos elementos 
pueden usarse de una 
forma bastante libre 
para construir un 
fichero escénico. 


No hay tabulaciones deter- 
minadas ni es preciso seguir 
un orden concreto en la co- 
locación de los elementos, 
si bien es adecuado atener- 
se a algun tipo de formato 
por criterios de claridad, so- 
bre todo si se va a desarro- 


llar un proyecto mediana- 
mente complejo En 
town.inc se advertirá un esti- 
lo determinado que el lec- 
tor puede sustituir tranquila- 
mente por otro con el que 
se encuentre más cómodo. 
Veamos ahora algo sobre los 
componentes del lenguaje. 


Instrucciones e 

identificadores 

El lenguaje escénico del 
POV consta de una larga lis- 
ta de instrucciones y pala- 
bras reservadas utilizadas 
como parámetros en dichas 
sentencias. El lector puede 
observar esta lista en la figu- 
ra sin sentir escalofríos; en 
principio basta con saber 
emplear bien unas cuantas 


sentencias y reglas para po- 
der realizar escenas bastan- 
te vistosas. La primera regla 
a recordar es sencilla: POV 
nos permite crear palabras 
para declarar objetos, colo- 
res, texturas, etc., y no po- 
dremos utilizar para ello 
ninguno de los nombres de 
la figura, dado que ya que 
están reservados para un 
uso determinado. Por ello, 
estos nombres, ya sean de 
instrucciones o de paráme- 
tros, reciben también el 
nombre de palabras reser- 
vadas. Por otra parte, las 
posibles palabras defini- 
bles por el usuario son lla- 
madas identificadores. Los 
identificadores pueden te- 
ner hasta cuarenta caracte- 
res de largo y se escriben 
con cualquier caracter alfa- 
bético o numérico, además 
de con el caracter *_'. (Aun- 
que el primer caracter del 
identificador deberá ser al- 
fabético y no numérico). Fi- 
nalmente, debemos recor- 
dar que no se permiten 
espacios dentro del nom- 
bre del identificador. Los 
identificadores se crean 
con Htdeclare. Por ejemplo: 
ttdeclare Chrome_Metal = 
texture [ Chrome_Texture ). 
Esta línea crea la textura 
Chrome_Metal. 


Comentarios 
Todos los lenguajes de pro- 
gramación tienen la posibi- 


a as. 


lenguaje escénico 


lidad de incluir comentarios 
a fin de facilitar la compren- 
sión del programa. Esta po- 
sibilidad es especialmente 
útil cuando un programador 
debe estudiar listados aje- 
nos. Pero incluso aunque el 
listado sea propio puede 
ocurrir que, con el paso del 
tiempo, ciertas líneas espe- 
Clalmente complejas se ha- 
gan difíciles de entender. 
Esta situación, también 
puede darse con el lengua- 
je escénico y, por ello, el 
pov-team ha incluido la po- 
sibilidad de introducir co- 
mentarios. Un comentario 
puede constar de una O 
más líneas de texto delimi- 
tadas por separadores y, su 
contenido, no tiene ningun 
efecto para la creación de 
la escena. Tan sólo servirá 
para hacer más comprensi- 
ble al lector el significado 
del listado. Los comentarios 
del lenguaje escénico del 
POV utilizan las mismas re- 
glas que los del € y C++. O 
sea una doble barra para los 
comentarios de una sola lí- 
nea y los caracteres /* y */ 
para los de una o más líneas. 
Veamos unos ejemplos: // 
Esta línea es un comentario 
y el POV la ignora /* Esta lí- 
nea es ignorada por el “intér- 
prete” que efectua el proce- 
so de parsing del POV. De 
hecho, todo es ignorado 
hasta el final de esta línea */. 
También, es posible insertar 


un comentario después de 
un trozo de línea “útil” del 
siguiente modo: object 
[cualquier_cosa) //El POV 
sólo ignora esta frase. 

Los comentarios también 
son muy útiles cuando se de- 
sea eliminar temporalmente 
un trozo de escena consis- 
tente en una o más líneas. Es 
mucho más fácil recuadrar el 
trozo con los símbolos de 
marca de comentario que 
simplemente borrarlo y vol- 
verlo a escribir después. 


Valores en formato 
flotante 
El manual de POV define un 
vector como un conjunto 
de valores en flotante. 

(El formato flotante es 
empleado para almacenar 


números con un compo- 
nente real y otro entero). Un 
vector puede tener de 2a 5 
componentes separados 
por comas y delimitados 
por los caracteres '<' y '>'. 
Los vectores pueden estar 
compuestos por expresio- 
nes numéricas, identificado- 
res o funciones que retoman 
valores. Ejemplos válidos de 
uso de vectores son: 
translate<Col2 ¡Row1 Dist> 
scale <1 ,2,1 ,-25.4578> 
location<posX,posY+15,- 
20> 
translate <años_luzX/densi- 
dad_estelar años _ luzY-+rand 
(a) +12 ,100>. 
Naturalmente, el número 
de componentes de un 
vector dependerá de la pa- 
labra que preceda a dicho 


Primitivas 
complejas de 
POV: objeto 
lathe. 


Rendermania 19 


NONENAENACACACAÍNIACACA 


vector. En rgbft serán 5, en 
una sentencia location se 
precisaran 3, etc. 


“Parsing” y ficheros 
include 

En POY, los archivos inclu- 
de son ficheros de texto en 


formato ASCII escritos con 
declaraciones o instruccio- 
nes del lenguaje escénico 
del pa cer naa se em- 


ciones (declaraciones) de 
objetos o cosas que pue- 
dan ser referenciadas una O 
muchas veces por los fiche- 
ros principales de escena. 
La mecánica de uso de los 
archivos de inclusión es la 
siguiente: en un lugar dado 
del archivo de escena, ge- 
neralmente al principio del 
mismo, se suelen colocar 
una o más Instrucciones co- 


mo la que sigue: ttinclude 
completas por si mr E Mc: 
aunque sí incorporan ele- le 
mentos para ellas. Su filoso- 
fía consiste en incluir defini- 


Figura 1: “Palabras reservadas de Povray” 


aa_level fog_offset reciprocal aa_threshold fog_type recursion_limit abs frequency 
red acos gif reflection acosh global_settings refraction adaptive glowing render 
adc_bailout gradient repeat agate granite rgb agate_turb gray_threshold rgbf all 
green rgbtt alpha halo rgbt ambient height_fíeld right ambient_light hexagon rip- 
ples angle hf_gray_16 rotate aperture hierarchy roughness arc_angle hollow sam- 
ples area_light hypercomplex scale asc if scallop_wave asin ifdef scattering asinh 
iff seed assumed_gamma image_map shadowless atan incidence sin atan2 inchu- 
de sine_wave atanh int sinh atmosphere interpolate sky atmospheric_attenuation 
intersection sky_sphere attenuating inverse slice average ¡or slope_map back- 
ground irid smooth bicubic_patch irid_wavelength smooth_triangle black_hole 
jitter sor blob julia_fractal specular blue lambda sphere blur_samples lathe sphe- 
rical_mapping bounded_by leopard spiral box light_source spirali box_mapping 
linear spiral2 bozo linear_spline spotlight break linear_sweep spotted brick loca- 
tion sqr brick_size log sqrt brightness looks_like statistics brilliance look_at str 
bumps low_error_factor stremp bumpy1 mandel strength bumpy2 map_type str- 
len bumpy3 marble striwr bump_map material_map strupr bump_size matrix 
sturm camera max substr case max_intersections superellipsoid caustics max_ite- 
ration switch ceil max_trace_level sys checker max_value t chr merge tan clip- 
ped_by mesh tanh clock metallic test_camera_1 color min test_camera_2 co- 
lor_map minimum_reuse test_camera_3 colour mod test_camera_4 colour_map 

> mortar text component nearest_count texture composite no texture_map concat 
normal tga cone normal_map thickness confidence no_shadow threshold co- 
nic_sweep number_of_waves tightness constant object tíle2 control0 octaves tiles 
control1 off torus cos offset track cosh omega transform count omnimax transla- 
te crackle on transmit crand once tríangle cube onion triangle_wave cubic open 
true cubic_spline orthographic ttf cylinder panoramic turbulence cylindrical_map- 
ping pattern? turb_depth debug pattern2 type declare pattern3 u default perspec- 
tive ultra_wide_angle degrees pgm union dents phase up difference phong 
use_color diffuse phong_size use_colour direction pi use_index disc pigment 
u_steps distance pigment_map v distance_maximum planar_mapping val div pla- 
ne variance dust png vaxis_rotate dust_type point_at veross eccentricity poly vdot 
else polygon version emitting pot vlength end pow vnormalize error ppm volu- 
me_object error_bound precision volume_rendered exp prism vol_with_tight ex- 
ponent pwr vrotate fade_distance quadratic_spline v_steps fade_power guadric 
warning falloff quartic warp falloff_angle quaternion water_level false quick_color 
waves file_exists guick_colour while filter quilted width finish radial wood fisheye 
radians wrinkles flatness radiosity x flip radius y floor rainbow yes focal_point 
ramp_wave z fog rand fog_alt range 
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comenzar a leer el fichero 
escénico suministrado co- 
mo entrada. Mientras el fi- 
chero se lee, POV va inter- 
pretando lo leido y 
creando un modelo interno 
de la escena. A este proce- 
so se le llama “parsing”, y 
“parser” a la parte de POV 
encargada de dicho proce- 
so. Pues bien, cuando du- 
rante el parsing del fichero 
dado como entrada, el par- 
ser halla una línea como la 
anterior, POV carga el fiche- 
ro indicado en la sentencia 
Htinclude y procede a inter- 
pretarlo. Al acabar con él, 


E er continúa leyendo 
el las líneas 
La sentencia a 3 ES Ds: 


del fichero” 


emplea para dar claridad a 
nuestros proyectos, ya que 
elimina la necesidad de te- 
nerlo todo en un único fi- 
chero. Así, podríamos crear 
5 tanques diferentes en 
otros tantos ficheros inclu- 
de y dejar en el fichero 
principal (el dado como 
entrada a POV) las senten- 
cias de cámara, luces y co- 
locación de los tanques. 
Para funcionar, Hinclude 
precisa que los ficheros .inc 
se encuentren en el directo- 
rio en curso, o bien en el di- 
reccionado por la orden de 
la línea de comandos +L. 
Povray adjunta en el direc- 
torio include varios archivos 
de inclusión con declara- 
ciones de colores 
(colors.inc), texturas (wo- 
Ods, stones...), etc., que 
nos serán muy útiles. Sin 
embargo, como los ele- 
mentos declarados ocupan 


espacio en memoria, no 
conviene “incluir” ficheros 
que no vayamos a emplear. 


Declare 
Los ficheros de inclusión 
utilizan mucho la instruc- 
ción fdeclare. Esto es así 
porque esta sentencia ayu- 
da considerablemente a es- 
tructurar las archivos escéni- 
cos, y hacerlos mucho más 
cortos y sencillos. Con ttde- 
clare se puede hacer que 
un identificador equivalga a 
una larga y compleja serie 
de sentencias que podrán 
ser referenciadas más tarde 
cuantas veces lo deseemos, 
simplemente incluyendo 


Para declarar un 
color, una textura compleja, 
un objeto o parte del mis- 
mo, un vector, un valor en 
flotante, una operación CSG, 
una cámara, etc. Con tde- 
clare bastará con cambiar la 
declaración que sigue a esta 
sentencia para que la altera- 
ción se haga efectiva en to- 
dos los sitios donde se haya 
colocado el identificador, 
con el consiguiente ahorro 
de tiempo y trabajo. 

Un detalle adicional muy 
importante es el hecho de 
que la declaración de un 
nuevo identificador puede 
apoyarse en otros identifi- 
cadores ya creados. 

Veamos un ejemplo váli- 
do extraido de colors.inc: 

ttdeclare White = rgb 1 

ttdeclare Gray05 = Whi- 
te*0.05 

Aquí el color blanco defi- 
nido es empleado en la de- 
finición del gris. Más tarde, 
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poreje 
ribir.. 
Hideclare X=5 


al estudiar town.inc, vere- 
mos como se emplea ttde- 
clare para definir objetos 
simples usados en la cons- 
trucción de otros más com- 
plejos (por ejemplo, venta- 
nas para las paredes, grupos 
de paredes para los pisos, 
pisos para las casas y grupos 

de éstas para un pueblo). 
Otra caracteristica muy 
importante de Hdeclare es 
que los identificadores cre- 
ados pueden ser redeclara- 
dos utilizando valor ante- 
rior del, identifi dor. Asi, 
lo, es posible es- 


Hideclare x1=X+7 

Hdeclare total=x1*(X+10) 

Donde el valor de “total” 
es de 180. La utilidad de to- 
do esto se hará evidente 
luego, cuando estudiemos 
las sentencias +Hif, Hwhile y 
otras. Una declaración 
siempre empieza, como 
podemos ver, con la pala- 
bra declare seguida del 
identificador. Luego, se po- 
ne un signo '=' al que segui- 
rá la definición de la decla- 
ración. (Recordemos otra 
vez que POV distingue en- 
tre mayúsculas y minúscu- 
las. No será igual “total” que 
“Total”). Los identificadores 
creados han usarse de ma- 
nera lógica. Es decir, si el 
identificador es un objeto, 
tendrá que ser referenciado 
dentro de una palabra ob- 
Ject. Si es una textura, ten- 
drá que colocarse dentro 
de una sentencia texture, 
etc. Veamos un ejemplo: 

HdeclareP_Gold2=rgb 
CVect2 


Hdeclare F_MetalA =finish [ 

brilliance 2 

diffuse D_GoldA 

ambient A_GoldA 

reflection R_GoldA 

metallic M 

specular 0.20 

roughness 1/20 

) 

Hdeclare T_Gold_2A = 
texture [ pigment [ P_Gold2 
) finish [ F_MetalA ] ) 

Como puede verse, la de- 
finición- de. la textura 

T_Gold_2A emplea el color 
P_Gold2 y el acabado 
F_MetalA (finish) definidos 
anteriormente. (Para la defi- 
nición de estas característi- 
cas, la textura emplea las 
palabras pigment y finish, 
de las que hablaremos más 
adelante). 

La declaración de un obje- 
to tampoco tiene misterios: 

Hdeclare bola=sphereí 
<0,0,0>, 1) 

El objeto declarado, ya 
sea sencillo como bola o 
muy complejo, puede ser 
invocado después en tan- 
tos sitios como deseemos 
empleando la sentencia 
object del siguiente modo: 

object [ bola 
texture([T_Gold_2A) scale 
<2,1,3>] 


object [ bola 
texture[T_Silver_4A) transla- 
te <10,20,30> ) 


Nótese como el identifi- 
cador del objeto bola es 
usado para crear dos obje- 
tos situados en posiciones 
y escalas diferentes, y que 
pueden llevar texturas dis- 
tintas. (siendo una de estas, 
la declarada en el ejemplo 
anterior). 


Tipos de objetos 
de POV 

Llamaremos figuras pprimiti- 
vas -O primitivas a secas- a 
los objetos simples que se 
definen con las sentencias 
reservadas para ello como 
sphere, box, plane y otras. 
Aquellos objetos más com- 
plejos, resultantes de las 
operaciones hechas entre 
objetos, no serán conside- 
rados como primitivas. A su 
vez, las primitivas pueden 
ser finitas o infinitas. Una es- 
fera es un objeto finito, ya 
que siempre tiene límites 
definidos sin importar cuán 
grande pueda llegar a ser. La 
primitiva plane, en cambio, 
tiene las mismas propieda- 
des que el plano matemáti- 
co. O sea, carece de grosor 
y se extiende infinitamente 
por el espacio virtual. 

La filosofía del modelado 
en POV se basa en operar 
con estas primitivas para 
construir objetos. Los obje- 
tos resultantes pueden su- 
marse o combinarse entre sí 
para producir objetos aún 
más complejos que pueden 
emplearse para crear mode- 
los de mayor complejidad. 


Primitivas 

La esfera es una de las pri- 
mitivas de más rápida inter- 
pretación de POV. 

Este objeto es generado 
con la sentencia sphere, cu- 
ya sintaxis es: sphere[ <cen- 
tro>, radio y. 

<Centro> es un vector 
que define los valores de 
X,Y y Z para la localización 
espacial del centro de la 
esfera. 

Después, separado por 
una coma, sigue el radio de 
la esfera. También, pode- 
mos generar esferas con 
otras sentencias como cua- 
dric pero sphere es más rá- 
pida. Un ejemplo sencillo 
es: sphere([<-12,4,0>,4 tex- 
ture(T_Stone23) ]. 

Esta línea creará una esfe- 
ra de 8 unidades de diáme- 
tro con una apariencia de 
piedra (textura T_Stone23) 
en la posición indicada por 
el vector. 

Otra primitiva sencilla y 
de rápido dibujo es box 
(caja). Un ejemplo sencillo 
de box sería un cubo o, da- 
do que la longitud de la 
forma no tiene porque ser 
la misma en los tres ejes, 


Primitivas 
complejas de 
POV: objetus 
Superellipscids 
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Superficies de - 
revolución. 


una caja de zapatos. La fi- 
gura se define especifican- 
do las posiciones espacia- 
les de dos vértices 
opuestos de la misma. Am- 
bos vértices son definidos 
por dos vectores separados 
por comas, con lo que la 
sintéxis de la caja queda 
como sigue: box[<esqui- 
na1>,<esquina2> ). 
También se supone que 
cada uno de los lados-es 
siempre paralelo a uno de 
los ejes de £oordenadas. 
Sólo posteriormente, con el 
empleo de sentencias de 
rotación “esta situación ini- 
cial pueda alterarse. Otro 
detalle importante a tener 
en cuenta es que el primer 
vector de la definición de- 
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be referirse siempre al ppun- 
to con los valores X,Y y Z 
más pequeños. 

Un ejemplo: boxf<- 
95,0,0> , <25,50,5> textu- 
re(textmur) ) 

La siguiente porimitiva a es- 
tudiar es el cilindro. La sen- 
tencia empleada para crear 
estos objetos es cylinder, y 
su sintaxis es... 

cylinder[<base>, <Cci- 
ma>, radio ] 

Los dos vectores indican 
las coordenadas X,Y y Z del 
punto central de cada ex- 
tremo del cilindro (de la 
base y la cima). 

El valor de “radio” especi- 
fica el radio del objeto. El 
cilindro creado aparecerá 
como un objeto “solido” a 


menos que escribamos la 
palabra “open” después 
del radio. En este caso, se 
eliminarán los planos que 
forman las dos bases del ci- 
lindro, con lo que éste que- 
dará hueco y sus paredes 
carecerán de grosor. Debi- 
do a este último detalle no 
se empleó open en los ci- 
lindros que definían las to- 
rres de castlib, ya que se 
pretendía que las torres, 
aunque huecas, tuviesen 
muros de un grosor dado. 
Por esta razón, la forma bá- 
sica de las torres se creó 
usando operaciones CSG 
entre cilindros. 

(Ver PCmanía número 47). 
Aquí tenemos un ejemplo 
de cylinder: 


cylinder 1<6,4,0>, 
<6,14,0>, 4 pigment [Red) ) 

(Pigment se emplea para 
crear una textura consistente 
en un color para el cilindro). 

Continuemos con el si- 
guiente objeto: el cono. Su 
filosofía y sintáxis son muy 
similares a las del cilindro. 
La única diferencia estriba 
en que ahora cada uno de 
los extremos del objeto lle- 
va un radio propio. También 
podemos emplear la pala- 
bra open después del se- 
gundo radio con el mismo 
resultado que antes. La sin- 
táxis para este objeto es... 

cone ([<base>, radio_ba- 
se, <techo>, radio_techo ] 
.. y el ejemplo correspon- 
diente... 


A RA AA —_———————— A A 


conel V 
<-12,1,0>,5 // Centro y ral 


dio de uno de los extremos Á plano tiene ds pesibles 
<-19,8,0>,3 // Center | 


Ñ 


y radio del otro extremo 
pigment (Cyan) 
) 

St se desea que el cono 
acabe en un único punto, 
debe dársele radio cero a 
uno de los extremos. 


Objetos infinitos, 
superficies 
matemáticas y 
plane 

Todos los objetos estudia- 
dos hasta ahora son finitos 
pero POV permite crear 
objetos con superficies in- 
finitas. Tal es el caso del 
plano, el cual es sumamen- 
te útil en las operaciones 
CSG. Otras primitivas que 
pueden caer en esta cate- 
goría son cubic, poly y 
quartic, las cuales descri- 
ben objetos basados en 
ecuaciones polinómicas. 
El cálculo de estas superfi- 
cies es lento y a veces no 
muy fiable. Además, pre- 
decir la forma final exacta 
de este tipo de objetos es 
difícil, por lo que estas pri- 
mitivas sólo suelen ser usa- 
das por programas de mo- 
delado. Por estas razones 
nos limitaremos a estudiar 
la primitiva “plane”. 

La palabra “plane” sirve 
para crear un plano, infini- 
to en dos de los ejes y ca- 
rente de longitud en el eje 
restante. Dicho plano pue- 
de ser utilizado como sue- 
lo o pared y puede recibir 
texturas en su superficie, o 
bien ser utilizado, como 


no al origen de coordena- 
das. De esta forma el ejem 
plo siguignté... 


folínatlys, 'amDos iguak | plane [ %0,1/Q>,5) 
Ame E el jyrimejo y A indica ue Ya normal 
¡SL lane, [ Aseráperpendicular al pla- 


no formado. poros ejes X 
y Z, como que obtendre-. 


raleta a 
ituadio a 5 


manera perpendisular 
éste, o sea como un paste 
en relación al suelo. S 
biendo esto es fácil imagi- 
nar que un vector paralelo 
al eje Y puede servirnos 
para crear un suelo mien- 
tras que otro paralelo al eje 
Z podría utilizarse para di- 
bujar un muro paralelo al 
plano que forma la panta- 
lla). El parámetro siguiente 
es un valor en flotante que 
indica la distancia del pla- 


gativos en el valor que 
gue al vector, la decisión 
acerca del lado del eje en 
que finalmente debe si- 
tuarse el plano, puede pa- 
recer un tanto liosa. 


Afortunadamente, basta- 
ra con que recordemos 
que el lado, positivo 6 ne- 
Sativo, se obtiene suman- 
do los signos del eje y et 
valor de distancia. O sea: 
positivo y positivo=dará 
positivo: 4l iguát-que ne- 

Sativo más negativo. 
Otra comtajnación mas. 
á o negativa del 


osterió 


nos (al menos en P 
tienen un “interior” y un 
“exterior”. 


POV: Blobs. - 
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Ejemplo de la 
librería de texturas 
de POV:oro. 


Texturas, colores y 


Ya sabemos bastante 
acerca de cómo crear 
objetos. De hecho, 
aunque no lo parezca, 
todos los modelos de 
Castlib se han creado 
partiendo de opera- 
ciones entre las primiti- 
vas ya estudiadas (tam- 
bién se ha empleado 
prism para puertas y 
ventanas). 


Aún no se ha tocado el te- 
ma de la apariencia de los 
objetos a pesar de que este 
asunto es de una importan- 
cia capital, ya que sin una 
textura que describa el ma- 
terial de una superficie, no 
sera visible. 


Materiales 

Comencemos con ello 
pues: para crear la aparien- 
cla de un material, el poten- 
te lenguaje de POV nos 
ofrece varias docenas de 
sentencias que empleare- 


mos para definir los ele- 
mentos constituyentes de 
las texturas: pigmentos, nor- 
males, acabados y halos. 
Un pigmento es el color o 
patrón de colores del mate- 
rial o bien el bitmap que lo 
recubre. El pigmento se de- 
fine con sentencias englo- 
badas dentro de las llaves 
de la sentencia pigment. 
Hay que decir que estos 
colores son los “reales” del 
objeto pero, bajo ciertas 
condiciones, no siempre 
serán los que se aprecien al 
obtener la imagen. Por 
ejemplo, si un objeto tiene 
un pigmento blanco y colo- 
camos una luz verde cerca 
de él, el objeto presentará 
un aspecto verdoso. En 
cuanto a “normal”, la sen- 
tencias escritas dentro de 
esta instrucción se emplean 
para crear apariencias tales 
como abolladuras, anillos, 
ondulaciones, etc., en el 
material. El nombre de esta 
sentencia hace referencia al 
método empleado para 
conseguir estos aspectos, 
logrados gracias a la distor- 
sión de las normales en la 
superficie del objeto don- 
de se aplica la textura. Es 
importante recordar que la 
superficie de los objetos no 
se vuelve realmente ¡rregu- 
lar. Se trata tan sólo de un 
truco que quedará en evi- 
dencia si observamos los 
bordes de las formas que 


empleen texturas de este ti- 
po. El siguiente apartado es 
el acabado, el cual se ob- 
tiene gracias a las senten- 
cias empleadas para la ins- 
trucción finish. (Aquí la 
palabra acabado alude a las 
propiedades reflectivas y 
refractivas del material). Por 
último, el apartado halo, in- 
corporado a partir de la 
versión 3.0 de POV, se em- 
plea para simular efectos 
de nubes, niebla, fuego, 
etc., dentro de los objetos. 

Una pov-textura puede 
ser de tipo sencillo o de ti- 
po especial. A pesar de su 
nombre, las texturas de tipo 
sencillo pueden ser muy di- 
fíciles de crear, dependien- 
do de lo que pretendamos 
hacer. El formato completo 
para una textura sencilla es: 

texture [ 

identificador_de_ Textura 

pigment (..) 
normal (..) 
finish ([..) 
halo 1.) 
Transformaciones 

) 

Las líneas anteriores po- 
darían incluirse dentro de las 
llaves de un objeto de este 
modo: 

box[<-4,2,-4>,<4,10,4> 
texture[defini- 
ción_de_textura) 
) 

Sin embargo, es mucho 
más cómodo declarar un 
identificador para la textura. 


INIEAPACA CA CACA CAR 


De este modo, la textura 
definida podrá ser emplea- 
da por tantos objetos como 
queramos sin necesidad de 
escribir todas las veces la 
misma definición. Por ejem- 
plo, podríamos escribir: 

Htdeclare madera=textu- 
re(definición_de_textura) 

box([<-4,2,-4>,<4,10,4> 

texture[madera) 
) 
sphere[<19,15,23>, 4 
texture[madera) ) 

Por otro lado, cada una 
de las líneas que anterior- 
mente vimos en el formato 
completo de la declaración 
de la textura pertenece a un 
apartado opcional en dicha 
declaración, aunque hay 
una excepción para esto: si 
“identificador_de_Textura” 
no se incluye, deberemos 
forzosamente dar un pig- 
mento a la textura. De he- 
cho, existe una forma abre- 
viada de definir una textura 
donde sólo se precisa defi- 
nir el pigmento. Así, la si- 
guiente línea es correcta: 
sphere(<2,75,13>, 6 pis- 
ment(White) ) 

Realmente, lo que sucede 
es que se aplican los valores 
de la textura por defecto pa- 
ra normal y finish. En caso de 
que pretendamos crear 
nuestra propia textura por 
defecto, podemos hacerlo 
usando la sentencia default. 

La siguiente línea, por 
ejemplo, cambiaría el valor 


por defecto de finish: Hkde- 
fault(finishíambient .7) ). 

Antes de continuar, con- 
viene tomar nota de una sen- 
tencia usada en pigment que 
nos será muy útil en las pprue- 
bas. Se trata de checker. Esta 
instrucción crea una trama 
de pigmentación tridimen- 
sional compuesta por cubos 
de colores alternos. La longi- 
tud de las aristas de cada cu- 
bo de color es de una uni- 
dad y la orientación de los 
cubos es paralela a los ejes 
del universo virtual. 

La importancia de che- 
cker radica en que equivale 
a una especie de srid tridi- 
mensional: un fondo con el 
que nos será fácil compro- 
bar si son correctas la colo- 
cación, orientación y escala 
de los objetos en construc- 
ción. El autor de estas líneas 
emplea mucho esta senten- 
cia en la aplicación de las 
primitivas con las que hace 
el suelo sobre el que irán 
los objetos en fase de de- 
sarrollo. Más tarde veremos 
muchos ejemplos de esto. 

Por ahora, veamos un 
ejemplo de checker: 

box[<-4,-4,-4>,<4,4,4> 

pigmentíchecker pig- 

mentíRed), pigment(Yellow)) 
) 

Esto puede abreviarse: 
box[<-4,-4,-4>,<4,4,4> 
pigmentichecker Red, 

Yellow)) 


transformaciones 


Al igual que otras senten- 
cias usadas en texturas, 
checker no limita su uso a 
un sólo tipo de componen- 
te de texturas. También 
puede ser empleada para 
alterar las normales del ma- 
terial. Por último, los pov- 
expertos deben tomar nota 
de que checker ha reem- 
plazado a tile para crear pa- 
trones ajedrezados de tex- 
turas. Por ejemplo.. 

plane(y,2 texture [ che- 
Cker texture[T_W00ad3]), tex- 
ture([T_Wood2)) ] 

..Crea un tablero de aje- 
drez de infinitas casillas alter- 
nando el uso de dos texturas 
de madera de la librería. 

Otro detalle muy impor- 
tante para la declaración de 
texturas es el hecho de que 
podemos aprovechar textu- 
ras ya creadas para definir 
las nuevas (lo cual también 
es válido para el caso de 
los pigmentos). En el for- 
mato completo de la decla- 


Ejemplo de la 
librería de 
texturas de POV: 
piedra y madera. 


Ejemplo de la 
librería de texturas 
de POY: cielo. 
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ración de textura sencilla 
que estudiamos anterior- 
mente figuraba la palabra 
identificador_de_Texjura, la, 
E cual es, sencillamente, el 
pS nombre de una textura ya 
___— declarada antes. Al incluir el 
identificador de una textura 

ya creada al principis de 


nuestra declaración, auto- 


qué especifiguémos p 
diches “Componerítes e 


TT bremprimirá”én Ed 
___ —aporados poreridentific 


te rocas, metales, 
maderas, cielos, cristales... 
En las siguientes líneas, por 
ejemplo, se declara una 
nueva textura de madera 
que es igual a la predefinida 
T_Wood17, pero cambian- 
do el valor de turbulencia: 
Hideclare 117 = texture 
[T_Wood17 


Un edificio 
con texturas 
aplicadas. 
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nuestra.eledlaración seTso- 
uestra-eleclaració , 


pigment( 
wood 
turoulence 0.0575 
] / / 


Podernós pues linpitamps a 
utilizar “tal cual” lás toduras 


les, 
ones lec eféctuaf- 
dela librería Ampiénerte E de, os dojerós péra 
ra 


ES empleandoTa sentencia E 
> con los archivos Gó- Sus 


de texturas y el estudio de 
su aplicación para crear ma- 
teriales complejos rebasa el 
propósito de este libro. Por 
tanto recomiendo a los 
pov-novatos que, al menos 
de momento, se limiten a 
emplear las texturas prede- 
finidas o bitmaps propios. 
No obstante lo que ya he- 
mos visto aquí sera sufiente 
para las escenas de prueba. 


| 
| 
| 


¡ 
| 
i 
J 
j 


j 
Esla 
Transformaciones / tufa del objeto. En el ejem- 
espaciales  / / / o anterior, las operaciones 
Otró aspectobásido eryel ay fectan a ambas cosas. 
seño de los Objetos eg el Ugo 
fe vs er al spati 
la 


mamoyasí aJas opera 
ue 


] 
j 
j 
| 
y 
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Traslación 

Ésta es la más simple de las 
transformaciones. Los valores 
en cada eje, en el vector, es- 
pecifican el número de uni- 
dades en que el objeto se 
desplazará a lo largo de los 
ejes de coordenadas. Estos 
valores no son absolutos, si- 
no relativos a la última posi- 
ción del objeto. ¡Recordar 
este detalle es vital! Por ejem- 
plo, en el ejemplo siguiente, 
2-AOQ4co- 


r sú pogición espácial, 
imenglones'o sy 'orien- 


al 


Ctacj n. Laprimera opera- 
) la la colocación de 
Os obfetos, la segunda altera 
las dimensiones de los obje- 
tos y la tercera sirve. $ j etcen 
la orientaciónf aptos y b 

Los tres tipos de transforma- 
ciones necesitan de un vec- 
tor que especifique los valo- 
res necesarios para los ejes X, 
Y y Z. Con ello, el formato de 


sphere([<5,5,5>,2 pigment 
(Red) translate<-2,10,-7> ] 


Escalación 


estas operaciones es: Con scale podemos alterar 
rotate <x,y,Z> las dimensiones de los ob- 
scale <x,y,Z> jetos usando factores de es- 
translate <x,y,Z> calado como parámetros 


para los ejes. Si los factores 
tienen el mismo valor en los 
tres ejes, las dimensiones 
del objeto afectado aumen- 
tarán o disminuirán pero la 
forma del objeto quedará 
igual. El factor de escala 


Podemos utilizar tantas 
operaciones de transforma- 
ción como queramos para 
un mismo objeto y emplear, 
asimismo, el orden que que- 
ramos para ellas. Por ejem- 
plo, es perfectamente válido 


escribir: multiplica las dimensiones 
sphere [ <0, O, 0>, 3 del objeto a lo largo del eje 
texture [ 117 ) correspondiente. Así... 
scale <1,2,1> sphere[<0,0,0>,2  pig- 
rotate <0,0,45> ment (Red) scale<.5,2,1> ] 
translate <-5, 90, 1> ..la esfera del ejemplo se 
rotate <35,0,0> estrechara en el eje X, que- 


) dando con una longitud de 
9 unidades. En el eje Y, en 
cambio, la esfera se alargará 
hasta las 8 unidades de lon- 
situd y la longitud en el eje 
Z quedará igual, ya que he- 
mos multiplicado su valor 


Como veremos, las trans- 
formaciones pueden aplicar- 
se al objeto completo, o sea: 
a su forma y textura o bien 
podemos hacer que afecten 
sólo a la geometría o a la tex- 


e 
a posiciól td y 
sino en la <3,15,-2>. 7 


original por 1 unidad. Es 
muy importante tener en 
cuenta que los cambios de 
escala son relativos al Últi- 
mo tamaño obtenido (se 
puede haber empleado 
más de una sentencia scale) 
y también a la posición del 
objeto. Por ejemplo, en el 
siguiente caso... 
sphere(<0,5,0>,2  pig- 
ment (Red) scale<.5,2,1> ) 
.. comenzamos con una es- 
fera centrada en X y Z, cuyo 
centro en el eje Y es la posi- 
ción 5. Como la forma de la 
esfera se multiplica por 2 en 
este último eje, el nuevo 
centro se desplazará a la 
posición 10, con lo que ha- 
brá un desplazamiento del 
lojeto en este eje. En los 


as 


ghterior, ya 
que el objeto esta EPETETAT 
trado en dichos ejes. Por lejey 


esta razón, es practicamen- 
te obligatorio efectuar la 
“construcción” de objetos 
complicados fijando su 
punto central (de los tres 
ejes) en la posición 
<0,0,0>. Por ello, si lo que 
queríamos era que la esfera 
del primer ejemplo queda- 
ra centrada en <0,5,0>, de- 
beremos escribir: 
sphere(<0,0,0>,2  pig- 
ment (Red) scale<.5,2,1> 
translate<0,5,0>)] 


Rotación 

La instrucción rotate girará 
el objeto el número de gra- 
dos que se indique en los 
parámetros para X, Y y Z. El 
Siro se efectúa siempre con 
respecto al centro de coor- 


denadas. Esto quiere decir 
que si el objeto está centra- 
do en dicho centro, rotará 
sobre sí mismo. En cambio 
si se halla a cierta distancia 
del centro parecerá descri- 
bir una órbita en tomo a la 
posición <0,0,0>. Por esta 
razón, si por ejemplo que- 
remos que un objeto cen- 
trado en la posición <21,- 
56,17> gire 45 grados en el 
eje X sin alterar su posición, 
deberemos escribir... 
translate<-21,56,-17> 
rotate<45,0,0> 
translate<21,-56,17> 
La primera traslación po- 
siciona el objeto en el cen- 
tro de coordenadas, la si- 
guiente rota el objeto los 
grados deseados y la terce- 
ra lo devuelve a su posición 
original (pero ya rotado). 
Nótese que realmente no es 


POV es llamado “de mano 
izquierda”. Ya sólo queda 


que tenemos dos objetos; 
una esfera y un cubo colo- 


advertir que el orden de las cados de tal manera que.el 


rotaciones influirá en el re” 


cubo (de mayor tamaño) se” 


sultado final. En la insirúc- super one al volumen es- 


ción: rotate<45,10,20>. 

El objeto rotaría primero 
45 grados en X, luego 10 en 
el Y y finalmente 20 en el Z. 
Si deseamos que el orden 
de las rotaciones sea distin- 
to habremos de usar dos o 
tres sentencias de rotación. 


Operaciones CSG 
entre objetos 
Nuestras escenas no po- 
drían ser demasiado visto- 
sas si se limitaran a mostrar 
objetos como cubos y es- 
feras con distintos tamaños, 
colores y posiciones. 


Afortunadamente, POV > 


cuenta con un factofáglicio” 
nal que-esdp pieza angular 


; — O E 
entá djérePosa la potencia 


Los valores dados a rotate 
pueden ser positivos o ne- 
sativos, lo que afectará al 
sentido del giro. Para recor- 
dar el sentido que tendrá 
una rotación positiva para 
cada eje, existe la siguiente 
regla. Mentalmente haremos 
el gesto de OK con la mano 
izquierda. Seguidamente, 
sin alterar el gesto, orienta- 
remos la mano de forma 
que el pulgar apunte en el 
sentido positivo del eje cu- 
yo sentido de giro intenta- 
mos recordar. El sentido 
positivo del giro será el mis- 
mo que siguen nuestros 4 
dedos cerrados (y el nega- 
tivo el opuesto, por su- 
puesto). Por esta razón el 
sistema de coordenadas de 


del diseño de objetos: las 
operaciones CSG. 

Estas operaciones, tam- 
bién llamadas booleanas, 
se emplean para crear nue- 
vos objetos realizando su- 
mas y restas con los volú- 
menes espaciales de dos o 
más objetos. Supongamos 


El mismo 
edificio con 


pigmentos 
simples. 


pacial ácupado por la mi- 
tad inferior de la esfera 
(comparte dicho espa- 
cio). Si restaimbs el cubo a 
la esfera, el resultado será 
una semiesfera. Si la resta se 
efectúa sobre el cubo el re- 
sultado será un cubo con 
un espacio esférico (recor- 
tado en su interior). 

Las transformaciones es- 
paciales estudiadas antes 
pueden aplicarse también a 
los objetos CSG. Pero lo 
más importante es que 'es- 
tos objetos pueden, a su 
vez, S usados en nuevas 
operaciones de CSG para 
producir nuevos objetos. 

De esto se deduce que, 
partiendo de primitivas 
muy sencillas (cajas, esfe- 
ras, Cilindros, etc.), pode- 
mos acabar obteniendo 
modelos de apariencia muy 
compleja. Este modo de 
trabajo también es llamado 
“Geometría de construc- 
ción de sólidos” porque 
sólo puede operar con ob- 
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La esfera roja 
alrededor del eje Y 
hasta superponerse 
a la casa, sobre la 
que efectuará una 
resta CSG. 
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jetos que tengan un volu- 
men interior definido. Las 
cajas y las esferas, por 
ejemplo, lo tienen, al igual 
que las primitivas de cilin- 
dros y conos -siempre que 
estas no empleen la pala- 
bra “open” (ya que enton- 
ces los objetos estarían 
abiertos y sin grosor en las 
paredes). 

POV dispone de 4 ope- 
raciones de CSG: union, 
difference, intersection y 
merge. 


Unión CSG 

Con esta operación, dos O 
más objetos se unen para 
formar uno sólo. Para crear 
una unión bastará con en- 
globar dos o más objetos 


dentro de las llaves de la 
palabra unión. 

Por ejemplo: 

union( 

box([<-5,-4,-10>, 
<5,4,10>]) 
sphere([<0,0,0>,4 
translate<10,15,0> ] 
pigment(Red) 
rotate <30,0,0> 

) 

En esta unión, la opera- 
ción de traslación sólo 
afecta a la esfera pero la ro- 
tación afecta a ambas for- 
mas y el pigmento se usa 
también para las dos. 

También podemos crear 
un identificador para esta 
unión y emplearla en más 
de un sitio (otra vez decla- 
re). La mayoría de las veces 
la unión se emplea para 
crear un Único objeto sobre 
el que se operan nuevas 
operaciones CSG. 


Difference CSG 
La palabra difference equi- 
vale a la resta de objetos. 
En esta operación la resta se 
efectuará sobre el primer 
objeto citado y los siguien- 
tes se emplearán como ob- 
jetos de resta. Veamos un 
ejemplo: 
differencel 
sphere[<0,0,0>,4 ] 
box([<-10,1.50,-10>, 
<10,10,10> ) 
box([<-10,1.50,-10>, 
<10,10,10> rotate 
<180,0,0> ) 
rotate <0,0,90> 
pigment(Red) 
) 
Aquí el resultado será una 
especie de llanta: la esfera 
de la que se restan las dos 


cajas. Nótese como ni tan 
siquiera nos molestamos en 
calcular los extremos de la 
caja inferior. 

Simplemente creamos la 
misma caja y la hacemos 
rotar 180 grados en X para 
que quede a ¡igual distan- 
cia en el lado negativo del 
eje Y. 

Finalmente, la segunda 
rotación afecta al objeto 
creado y lo gira para que la 
llanta pueda “rodar” 


intersection CSG 
En la intersección, el obje- 
to resultante será el forma- 
do por los volúmenes es- 
paciales que compartan 
todos los objetos usados 
en esta operación. Las si- 
guientes líneas: 
intersection ( 
sphere [ <0, O, 0>, 4 
translate <-2,0,0> ] 
sphere [ <0, 0, 0>, 4 
translate <2,0,0> ] 
pigment [ Red ] 
) 
.. Crean una especie de ba- 
lón de rugby creado con el 
volumen espacial que am- 
bas esferas compartían. 


Merge CSG 

Esta operación funciona 
exactamente ¡gual que 
unión. 

La única diferencia estri- 
ba en que las partes com- 
partidas de los objetos usa- 
dos con merge (fusion) 
desaparecen. 

Esto es útil cuando se es- 
tan aplicando texturas no 
opacas (cristal, hielo, etc.), 
donde puedan verse partes 
intemas. 


Planificar un proyecto 


Al idear un proyecto 
para crear escenas O 
animaciones es preciso 
tener en cuenta una 
serie de factores que 
influirán en el buen 
desarrollo del mismo. 
En primer lugar, hay 
que tener en cuenta la 
escena en sí; qué 
objetos van a 
componerla, cómo 
vamos a construirlos, 
las texturas que se 
emplearán... 


A partir de esto, hay que in- 
tentar adivinar si la realiza- 
ción del proyecto es facti- 
ble, teniendo en cuenta el 
hardware y el tiempo de 
que se dispone. Otro factor 
adicional que puede aca- 
bar siendo un verdadero 
problema para algunas per- 
sonas es el gusto por el de- 
talle. Uno puede comenzar 
con una idea relativamente 
sencilla como la de un cas- 
tillo compuesto por 2 o 3 
torres sencillas, un par de 
muros y un montecillo don- 
de colocarlo todo. Sin em- 
bargo, conforme se van cre- 
ando objetos, uno puede 
acabar entuslasmándose de- 
masiado, y acabar intentan- 
do crear una auténtica ciuda- 
dela amurallada, con 
docenas de casas distintas y 
un enorme castillo de fondo. 

Esto fue lo que sucedió 
en el caso de Castlib. En un 
momento dado, pensamos 
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colocar casas alrededor del 
castillo para darle mayor 
realismo. Estas casas tan só- 
lo servirían de fondo para la 
estructura principal (el cas- 
tillo) y nunca se verían de 
cerca, por lo que no preci- 
sarían demasiado detalle. El 
caso es que, sin saber co- 
mo, al final las casas co- 
menzaron a recargarse con 
detallitos, variaciones, tex- 
turas propias, etc. El tiempo 
se acababa y las estructuras 
del castillo... ¡Por el rayo tra- 
zado con calidad 9! No es- 
taban listas. Pero, en fin, de 
todos modos town.inc (fi- 
chero extraido del proyec- 
to original) nos servirá para 
ilustrar los pormenores de 
la creación de un proyecto 
y algunas nuevas caracterís- 
ticas y sentencias de POV 
3.0. Antes de comenzar, no 
obstante, queremos dejar 
claro que, en parte, lo que 
se dice en este capítulo es 
bastante subjetivo. Vamos a 
estudiar el desarrollo de un 
proyecto, pero siempre hay 
más de una manera de ha- 
cer las cosas y otros usuarios 
de POV pueden emplear 
métodos distintos y no ne- 
cesariamente Inferiores. 


Evolución de un 
proyecto 

A pesar de su antiguedad, 
la idea inicial de Castlib no 
ha cambiado gran cosa. Di- 
cha idea consistía en dise- 
far unas cuantas estructuras 


sencillas que se combina- 
rían entre sí de diversos 
modos para crear otras algo 
más complejas, las cuales, a 
su vez, tambien podrían 
combinarse para crear cons- 
trucciones de complejidad 
aún mayor. De este modo, 
se esperaba que las escenas 
aparentasen una compleji- 
dad algo elevada a cambio 
de un esfuerzo de modela- 
do relativamente bajo. 

Lo que sí ha experimenta- 
do cambios en Castlib ha 
sido la forma de construir 
los objetos básicos. Al 
principio, por ejemplo, las 
torres circulares se cons- 
truían utilizando un enorme 
cilindro como cuerpo. Este 
cilindro podía tener 10, 20, 
30 o incluso más metros vir- 
tuales. A este objeto se le 
practicaban restas CSG (dif- 
ferences) para las ventanas, 
se le añadían (union) mar- 
cos para estas, aspilleras 
para las almenas, etc. Natu- 
ralmente, cuanto mayor fue- 


Este es el 
panel básico 
con el que se 
construyen los 
demás. 


Paneles 
diagonales 
para muros 
bajo tejados. 


se la torre a crear, mayor era 
el número de restas boolea- 
nas a efectuar sobre el cilin- 
dro y mayor también el nú- 
mero de objgtas a añadir. 
Mientras+tas torres fueron 
relativamente pequeñas no 
hubo problemas pero muy 
pronto quedó patente una 
cosa: con torres, relativa- 
e mente grandes, llenas de 


des, el tiempo de genera- 
ción de la escena se dispa- 
rabah El proyecto no 
resultaba práctico. Por 
aquel entonces (usando la 
versión 2.0) no empleába- 
mos bounding_slab. Al pa- 
sar a utilizar dichas figuras, 
los tiempos de generación 
disminuyeron bastante, pe- 
ro pronto, cuando las esce- 
nas aumentaron un poco el 
nivel de detalle, se compro- 
bó que esto era insuficiente. 
El problema estaba relacio- 
nado con un sistema emple- 
ado por POV para acelerar 
los tiempos de cálculo. 


¿Na E Tego para una caja 


Una de las cosas para las que 
POV requiere más tiempo de 
cálculo es la comprobación 
-para cada rayo a trazar- de si 
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entanas y torrecitas ados" 


hay o no intersección con las 
superficies de los objetos. 
Hay que pensar que por ca- 
da pixel se lanza un rayo que 
POV debe comprobar con 
todos los objetos de la esce- 
na. Además, se realizarán 
comprobaciones adicionales 
si hay que estudiar reflexio- 
nes, refracciones, etc. 

Como siempre, la mejor 
manera de ahorrar tiempo es 
hacer los menos cálculos po- 
sibles y, para ello, POV em- 
plea el truco de los objetos 
bounding_slab. Los boun- 
dig_slab son objetos invisi- 
bles, normalmente esferas O 
cajas, que POV o el usuario 
definen alrededor de los ob- 
jetos complejos de la esce- 
na. Al usar esta técnica, POV 
comprueba primero si el ra- 
yo intersecciona con alguna 
bounding_slab y de ser así 
pasa a realizar los cálculos de 
intersección con el objeto 
enslobado por la bounding 
detectada. Si no es así, el ra- 
yo se desestima. Como es 
mucho más rápido calcular 


stera que para los 


recubrir, el ahorro de 


se hace considerable. Otro 
detalle a tener en cuenta es 
que el bounding puede ha- 
cerse anidado. Es decir, pue- 
de haber un objeto boun- 
ding que recubra un modelo 
complejo y, a su vez, otros 
boundins interiores que re- 
cubrirán partes del modelo. 

Naturalmente, para que es- 
ta técnica resulte efectiva, es 
preciso que los objetos 
bounding sean objetos rápi- 
dos de calcular (cajas o esfe- 
ras) y que se ajusten lo mejor 
posible a los objetos que en- 
globan. Si el recubrimiento 
no es perfecto (o sea: si lo 
hacemos manualmente y cal- 
culamos mal las dimensiones 
o colocación del objeto 
bounding), podemos perder 
tiempo de cálculo o peor 
aún, hacer que queden invi- 
sibles partes de la escena. 

POV realiza un bounding 
automático que se ha ido ha- 
ciendo más y más efectivo en 
cada nueva versión, pero que 
aún no es perfecto, ya que el 
bounding automático de 
POV no funciona bien en cier- 
tos casos, sobre todo en ob- 
jetos CSG con los que se han 
empleado objetos infinitos. 

Si el usuario desea colocar 
manualmente los objetos 
bounding, puede usar la sen- 
tencia bounded_by, la cual 
tiene el siguiente formato: 

bounded_by [ object_ 
bounding ( ...)] 

Y en el manual de POV se 
cita el siguiente ejemplo.. 

intersection [ 

sphere [ <0,0,0>, 2] 

plane [ <0,1,0>, 0] 

plane [ <1,0,0>, 0] 


% ES [ sphere ( 


<0,0,0>,2)) ) 

Aquí el usuario ha definido 
una esfera situada en el ori- 
gen de coordenadas y con 
radio 2 para englobar este 
objeto CSG. 

Sin embargo, parece claro 
que, sobre todo a partir de la 
versión 3.0, el uso de esta 
sentencia será cada vez más 
raro. Ello se debe en parte a 
que el bounding automático 
de POV es, a menudo, más 
preciso y mejor que el que 
puede especificar el usuario 
y además al hecho de que 
pocas veces se emplean ob- 
jetos infinitos en las opera- 
ciones CSG (salvo plane). 


Un truco sencillo 
para ganar tiempo 
Ahora que ya sabemos algo 
sobre una de las técnicas 
empleadas por POV para ga- 
nar tiempo volvamos a nues- 
tro proyecto. Habíamos di- 
cho que en las escenas con 
torres grandes el tiempo de 
cálculo se disparaba. Ello se 
debía, como ahora quedará 
claro, a que se estaba em- 
pleando un método erróneo. 
Cuando debamos crear es- 
tructuras que empleen un 
buen número de operacio- 
nes CSG no debemos crear 
un único objeto, sino un ob- 
jeto compuesto por otros. 
¿Qué quiere decir esto? En 
el ejemplo comentado antes, 
una torre era un único objeto 
sobre el que se practicaban 
restas para las ventanas, puer- 
tas y partillas, y adiciones pa- 
ra los marcos correspondien- 
tes. El resultado podía 
presentar un aspecto bastan- 
te complejo pero no por ello 


U 


de 


E 
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dejaba de ser un único objke- 
to. Por esta razón, dentro del 
volumen espacial de la torre, 
POV debía emplear muchos 
testeos para saber si el rayo 
estaba tocando alguno de 
los muchos marcos de venta- 
na o los agujeros de estas, 
etc. Así, en el siguiente paso, 
procedimos a construir pisos 
que después se apilarían uno 
encima de otro para montar 
las torres. De esta manera, al 
dividirse cada torre en varios 
pisos, POV pasó a crear un 
objeto bounding para cada 
piso, aparte del empleado 
para la unión de todos estos 
pisos, o sea: la torre. Con 
ello, al realizarse menos 
comprobaciones de inter- 
sección con los detalles de la 
torre (marcos, agujeros, etc), 
el tiempo de generación se 
redujo mucho. 


Variaciones 

El descubrimiento del pe- 
queño detalle citado más 
arriba fue el factor principal 
que llevó a tirar al cubo la 
versión anterior de Castlib y 
volver a comenzar el trabajo 
casi desde cero. Los diseños 
iniciales también fueron a pa- 
rar al cubo debido al descu- 
brimiento colateral de que, 
en unas estructuras que se 
montan a base de pisos, re- 
sulta posible combinar las 
construcciones de muchas 
maneras distintas, si las altu- 
ras y dimensiones coinciden. 

Sin embargo, a fin de apro- 

vechar a fondo la idea de la 
variación, se necesitaba A 
número mínimo ide .pis s 
bastante diferentes entre sí. 
ebido a esto, y pensando 


castillos se llenaran en ca 
bio de escenas de casas. 


Documentación 

Otro aspecto fundamental a 
la hora de crear una escena 
poblada con objetos no abs- 
tractos es la documentación. 
Para las escenas que se dese- 
aban crear en este proyecto 
no se pretendía de ningún 
modo ceñirse a un estilo ar- 
quitectónico dado. Lo único 
que se esperaba era que los 
modelos fuesen sencillos pe- 
ro resultones y por ello la do- 
cumentación se tomó de 
fuentes tan diversas como los 
espléndidos escenarios del 
magnífico comic “Principe 
valiente” de Harol Foster (una 
obra de arte del género), las 
cuidadas viñetas de “Perce- 
van”, e incluso las delirantes 
páginas de “Groo”, de Sergio 
Aragonés. 

También se consultó el ex- 
celente libro ilustrado; “un 
castillo medi l, publicado 

aquí por Círculo de Lectores 
y se examinaron otras fuen- 
tes: Portofolios de artistas co- 
mo Rodney Matthews, vi- 


POV puede crear casi C 
quier tipo de textura imagina- 
ble empleando algoritmos; 
madera, piedra, marmol, etc. 
(Por ello, también se llama 
“procedurales” a estas textu- 
ras). El código de POV gene- 
rará diversos resultados se- 
gún el tino con el que 
hayamos empleado las sen- 
tencias de texturas que con- 
trolan a estos algoritmos. Los 
materiales creados de este 


El panel 12: 
una puerta y 
una ventana. 


Nx AS 
xx 
modo den PAY tienen la 


plo, se tomó la textura de 
dera empleada en diversos 
sitios. Otro detalle que aho- 
rró mucho tiempo fue la ob- 
tención de dos pequeños y 
bonitos bitmaps de piedras 
de muros. Hecho esto, sólo 
restaba ver cómo diseñar las 
Casas, a fin de aplicarles uno 
de estos bitmaps. 
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_ Estos son 
-———-" TT los paneles A 
Mauro. 


Esto es lo que 
sucedería con rotate 
zx45 dentro de la 
sentencia de la 
textura. 
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cualquier resolución razona- 
ble. El formato para usar esta 
sentencia es: pigment [ ima- 
ge_map [ formato “filename” 
modificadores ) ) 

En “formato” pondremos la 
palabra correspondiente al 
tipo de archivo bitmap que 
vamos a usar, gif, tga, png u 
otros. A esto sigue, entreco- 
millado, el nombre del archi- 
vo, el cual será buscado por 
POV en el directorio en curso 


ejes Xe Y en el sentido -Z 
(entrando en la pantalla, se- 
gún el ejemplo del princi- 
pio). De no ordenar otra co- 
sa, la textura se aplicará en el 
área rectangular delimitada 
por las coordenadas (0,0) a 
(1,0). Este área de aplicación 
puede trasladarse, rotarse o 
escalarse sobre el plano de 
aplicación (que por defecto 
es el formado por los ejes X 
e y) utilizando las mismas 
sentencias usadas para ope- 
rar con los objetos (o sea 
translate, rotate y scale). 

En caso de que el tamaño 
del area de aplicación, una 
vez transformada o no, resul- 
te insuficiente para cubrir al 
objeto, la trama del bitmap 
se repetirá sobre éste tantas 
veces como sea necesario, 
hasta que toda la superficie 
quede “pintada”. POV dis- 
pone del modificador 
map_type para permitimos 
cambiar el tipo de aplicación 
del bitmap. Map_type va se- 
guida de un valor con el que 
indicaremos este detalle; O 
es el valor por defecto y el 
que corresponde a una apli- 


cación plana, 1 realiza un 
apeado esférico sobre el 
bojeto, 2 efectúa un mapea- 
do cilíndrico y 5 un mapea- 
do toroidal (para objetos 
con forma de donut). La for- 
ma del mapeado afectará a la 
apariencia del objeto. 


Diseño elegido 

Es fácil imaginar que las casas 
que ilustran estas páginas 
pueden modelarse de distin- 
tas formas. Se podría, por 
ejemplo, haber creado cajas 
de diferentes tamaños, y ha- 
ber aplicado el bitmap a ca- 
da pared desplazando y ro- 
tando el plano de aplicación 
del mismo. 

Este sistema, en concreto, 
fue considerado y finalmen- 
te desechado por parecer 
poco flexible y demasiado 
trabajoso. Había muchas par- 
tes cuya escritura habría de 
repetirse y paredes que exis- 
tirían pero que no se verían, 
con la consiguiente pérdida 
de tiempo en cálculos inúti- 
les. En lugar de esto, se optó 
por otro sistema bastante ra- 
dical. Se decidió crear una 
colección de paredes o pa- 
neles diferentes que se em- 
plearían para crear todas las 
casas. Un panel podía ser un 
muro con vigas cruzadas, 
una pared con puertas o ven- 
tanas, etc. De este modo, un 
montón de casas diferentes 
podía definirse con poco 
esfuerzo definiendo los mo- 
delos como uniones de pa- 
neles y otros objetos. Con 
esta filosofía una casa senci- 
lla es, simplemente, 4 pare- 
des a las que se les ha pues- 
to un techo. 


Un poblado 


medieval 


En town.inc hay 
declaradas cerca de 50 
estructuras utilizables 
de diversa 
complejidad. 


Aunque se ha intentado se- 
guir un cierto orden, obser- 
varéis que en las casas de 
distintos tamaños se em- 
plean métodos diferentes. 
Esto se ha hecho así en par- 
te por capricho, para averi- 
guar que método era el más 
práctico, en parte por inten- 
tar ilustrar diferentes méto- 
dos para llegar a resultados 
similares y en parte porque 
un sistema que funciona 
bien en un tipo de objetos 
no tiene porque ser ¡gual- 
mente válido para otros. 


La primera pared 
Ante todo era preciso es- 
coger un sistema de medi- 
das para construir los obje- 
tos y calcular distancias. En 
Castlib, por definición, 10 
unidades de POV equivalen 
a un metro. Otra norma ele- 
gida fue que el suelo, don- 
de se colocarían los esce- 
narios, estaría formado por 
el plano X-Z, a la altura Y=0 
del origen de coordenadas. 
Definidas estas reglas, el 
primer objeto creado fue 
una sencilla caja que repre- 
sentaría un trozo de pared 


de 5x5 metros (50 pov-uni- 
dades por cada lado). A 
este primer objeto, al que 
luego se le añadieron vigas 
en los lados, se le llamó pa- 
nelb (por panel básico) 
Como el bitmap se aplica 
por defecto en el plano X- 
y, el panel fue colocado pa- 
ralelamente a dicho plano. 
Además, como se cons- 
truirían nuevos paneles to- 
mando el básico como ba- 
se y como dichos nuevos 
paneles tendrían, a veces, 
que ser rotados para colo- 
car las paredes laterales de 
las casas, panelto se definió 
centrado en el eje Z. Como 
las paredes son todas verti- 
cales (paralelas al plano X- 
Y) no era preciso centrar el 
panel inicial en Y, por lo que 
se colocó esta primera pa- 
red justo encima del suelo. 
A esta pared inicial se le 
colocó el bitmap. Dicho 
bitmap, que no ha sido in- 
cluido con los fuentes de 
Castlib por no tener dere- 
chos de distribución sobre 
el mismo, es una imagen de 
una trama de rocas. Esta 
imagen es “tileable”, como 
suelen decir los grafistas, O 
sea que las rocas de un la- 
do encajan con las del ex- 
tremo opuesto del bitmap. 
Esta característica es suma- 
mente útil por dos razones: 


la primera porque, aunque 
se aprecie repetición, no se 
notarán fallos al aplicarse 
repetidamente la textura y 
la segunda porque no ha- 
brá que preocuparse de la 
posición en que se colo- 
que ésta sobre el muro. La 
pongamos como la ponga- 
mos encajara. 

De lo que si había que 
preocuparse era del tama- 
ño relativo que tendrían las 
rocas del bitmap sobre el 
muro. Como se dijo antes, 
el plano de aplicación de la 
textura se extiende por de- 
fecto sobre un área cuadra- 
da de 1 unidad de largo. 
Esto significa que, como el 
muro tiene 50, la imagen se 
repetiría 50 veces por cada 
lado. O sea que no vería- 
mos ladrillos sino tan sólo 
un feo punteado. Para re- 
mediar esto bastaba con 


Aquí puede verse 
cómo un distirito 
vaor de seed sirve 
para gerierar calles 
diferente. 


————— escala ítmap. Exámine- 
mos la declaración der Ob- 


¡eto panelb: 
Baectare panel 


objectiviga translate 
<-25,25,0>) 

objectiviga translate 
<95,25,0>+) 

Como vemos, panelt se 
ha declarado como una 
unión de objetos. El primer 
componente de la unión es 
la caja que hará las veces 
de muro y los 4 siguientes 
son las 4 vigas de madera 
que bordean el muro. (Las 
vigas son tan sólo cajas alar- 
gadas con texturas de ma- 
dera). Después de la sen- 
tencia image_map siguen 
dos operaciones de trans- 
formación. la primera, 
translate, no tiene demasia- 
da importancia y sirve tan 
sólo para que, al centrar el 
área de aplicación de la 
textura en <0,0,0>, la apli- 
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do la ladrillada diagonal 
que puede verse en una de 
las imagenes. 


Más tipos de muros 
Una vez definido el panel 
básico, podemos crear un 
nuevo panel basándonos en 
el ya creado. Por ejemplo: 
1/ con puerta a la IZQ. y 
ventanita tipo 1 a la der. 
tideclare panel11=union( 
difference! 
object[panelb) 
object[recpuerl 
translate <-14,0,0>) 
objectirecven1 
translate <12,25,-1>) 
h 
objectípuerta transta- 
te<-14,0,1>) 
object[marcove1 
translate <12,25,2> ) 
) 
...se declara el panel núme- 
ro 11. Examinemos la decla- 


tra en la misma posi- 
y orientación espacia- 
es y hereda las mismas pro- 
piedades (tamaño, materia- 
les, etc.) que el original. Los 
objetos de resta empleados 
se hallan definidos al princi- 
pio de town.inc y son agu- 
Jeros para crear una puerta y 
una ventana. Estos agujeros 
son trasladados -ya que 
también estaban creados 
de forma centrada en el ori- 
gen- a las posiciones donde 
irán los marcos de la puerta 
y la ventana. Los objetos- 
marco son los otros tres 
componentes de la unión. 
(Nótese que los tres obje- 
tos situados dentro de las 
llaves de la operación diffe- 
rence NO son parte de la 
unión. El resultado de la 
operación de diferencia, en 
cambio, es un objeto del 
cual Sl podemos decir que 
es un elemento de la union). 
El nuevo objeto declara- 
do; panel11, puede a su 
vez, serempleado en la de- 
claración de nuevos obje- 
tos (esta potente caracterís- 
tica de POV nos ahorrará 
muchas líneas de texto). Po- 


démos comprobar este de- 
tdlle fijándonos en la decla- 
lación del panel12. 

1/ con puerta a la ¡zQ., 
ventanita tipo 1 a la der. y 
viga diagonal 

Hdeclare panel12=union([ 

object(panel11) 
objectíviga scale 
<1.5,1.33,1> rotate z*45 
translate <0,25,-0.2>) 

) 

Con tan sólo tres líneas de- 
claramos el panel12. En di- 
cha declaración se crea un 
nuevo objeto que es la unión 
entre una copia del panel! 1 
y una viga cruzada diagonal- 
mente sobre el panel. 


Trucos 

Una vez definidos los 15 pa- 
neles que forman nuestra co- 
lección, y con los que se han 
definido todas las casas de 
town.inc, es el momento de 
crear nuestra primera casa. 
Antes los pov-novatos debe- 
rían tomar nota de algunos 
trucos sencillos: 

1) Casi siempre, el objeto 
debe construirse centrado 
en el origen de coordenadas. 

9) Recordad que si un ob- 
jeto está situado a cierta dis- 
tancia del centro de coorde- 
nadas es muy fácil crear un 
nuevo objeto -idéntico- en 
una posición comprendida 
dentro del círculo que forma 
el radio desde la posición 
del objeto original hasta et 
origen de coordenadas. Este 
truco se empleó, por ejem- 
plo para colocar las aspilleras 
de las torres circulares (ver 
PCmanía 47). Primero se de- 
finía una aspillera a x distan- 
cia del origen y luego las de- 


más se definían haciendo 
una copia rotada x grados 
con respecto a la original. 

3) Es muy útil colocar cá- 
maras en los ejes que apun- 
ten al origen de coordena- 
das, donde hemos colocado 
al objeto en construcción, de 
este modo tendremos las vis- 
tas: frontal, lateral, superior, 
etc. Si la cámara apunta al 
centro del objeto será más 
fácil detectar imperfecciones 
en la simetría y otros detalles. 

4) También es muy útil de- 
finir un plano con checker 
como suelo donde se colo- 
carán los objetos que vaya- 
mos a construir. De este mo- 
do, podremos ver si las 
medidas y distancias entre 
objetos son correctas. En 
Castlibb el metro equivale a 10 
unidades por tanto debere- 
mos escalar el checker por 
10 para que cada cuadro 
equivalga a uno de nuestros 
metros virtuales. 


Levantar casas 

Se han empleado leves varia- 
ciones en la idea básica para 
crear los distintos tipos de 
casas. Sin embargo, el méto- 
do ha sido siempre el mis- 
mo: definir uniones de obje- 
tos-muro, colocados y 
rotados convenientemente. 
Normalmente, cuando la ca- 
sa bba a tener más de un piso, 
se procedía a declarar pisos 
y luego la casa se definia co- 
mo una unión de pisos diver- 
sos. El segundo piso se colo- 
caba (translate <0,50,0>) a 5 
metros de altura (Y) sobre el 
primero, el siguiente a 10 
metros, etc. Naturalmente, 
también se han empleado 


otros objetos; los marcos pa- 
ra ventanas y puertas, por 
ejemplo, se crearon em- 
pleando la sentencia Prism 
descrita en PCmanía 47. Las 
buhardillas son casas -que 
emplean panelb en todos 
sus muros- a las que se han 
aplicado operaciones de es- 
calado y sobre las que se ha 
puesto una ventana sin esca- 
lar. Los tejados... Lo impor- 
tante es que para usar 
town.inc, el usuario sólo ten- 
drá que colocar la necesaria 
sentencia Hinclude en su fi- 
chero, y citar desde allí los 
objetos cuyo nombre em- 
pieza por “casa”. Las casas 
de 1 a 10 tienen 10 metros 
de altura, las de 20 a 99 tie- 
nen un piso extra, y así suce- 
sivamente. Si el lector exami- 
na town.inc observará 
ocasionalmente identificado- 
res con nombres tales como 
casa32a, casa34c, etc. Estos 
nombres indican que el ob- 
jeto es una variación del di- 
seño original. 


Levantar calles 

Una vez listos para crear el 
pueblo surge el problema de 
qué método emplear. Pode- 
mos colocar las casas a ma- 
no pacientemente pero ha- 
brá que hacer muchas 
pruebas, ya que seguramen- 
te cometeremos muchos 
errores en la creación de las 
calles; casas que se superpo- 
nen unas a otras, excesiva 
distancia entre las mismas, 
etc. La verdad es que el mé- 
todo más sencillo se basa en 
emplear algunas de las nue- 
vas sentencias de POV 3.0. 
No vamos a describir ahora 


estas sentencias (ya lo co- 
mentamos en PCmanía 47), 
pero si diremos que aquellos 
que tengan nociones de pro- 
gramación no tendrán ningun 
problema con ellas. En el fi- 
chero generador de las pov- 
ciudades se emplen dos bu- 
cles ttwhile para crear una 
rejilla de casas. La colocación 
de una casa u otra se decide 
usando el generador de nu- 
meros pseudoaleatorios que 
incorpora POV (funciones 
RandO y Seedo) y la función 
intO. También se emplean 
sentencias Switch y sus co- 
rrespondientes Htcase. Todas 
estas sentencias tienen un 
uso casi idéntico al que po- 
dríamos esperar en un len- 
guaje de programación. Hay 
que subrayar un detalle muy 
atractivo; cambiando el valor 
dado como semilla a la fun- 
ción seed(, los valores sumi- 
nistrados por Rand() cambia- 
ran y el resultado será un 
pueblo totalmente diferente. 


Ciudades 

Podríamos imaginar que las 
ciudades que podemos 
crear pueden tener cientos, o 
miles de edificios pero esto 


no es posible. Aunque los fi- 
cheros escénicos ocupan 
muy poca memoria, el mo- 
delo interno que construye 
POV para generar las escenas 
si necesita bastante RAM. Os 
aconsejamos que no creéis 
declaraciones de bucles whi- 
le de objetos, ya que enton- 
ces se requerirá bastante más 
memoria al necesitarse espa- 
cio para el modelo declara- 
do y la copia invocada. Des- 
conocemos los detalles 
exactos acerca del modo en 
que POV gasta memoria. Tan 
sólo podemos repetir lo que 
hemos visto en las pruebas. 
En cuanto a las fotos, no 
hay mucho que destacar. Bá- 
sicamente sólo se usaron dos 
cámaras para todas ellas cam- 
biándose casi siempre, en 
cambio, el valor de seed y el 
número de columnas y filas. 
Notad el fallo cometido en 
una de las fotos. La rutina ex- 
tiende la ciudad desde un 
punto alejado de la posición 
<0,0> de X y Z. Como en di- 
cha foto se utilizó una esfera 
para simular el mundo, y sólo 
tenía 100.000 unidades de ra- 
dio, el resultado fue que las 
casas parecen flotar en el arre. 
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